From ltru-bounces@ietf.org Mon Jan 01 12:26:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Qvo-0006eJ-8N; Mon, 01 Jan 2007 12:26:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Qvn-0006bo-Oz for ltru@lists.ietf.org; Mon, 01 Jan 2007 12:26:39 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1QrH-0001Cr-VD for ltru@lists.ietf.org; Mon, 01 Jan 2007 12:22:01 -0500 Received: from [10.72.72.253] (snvvpn1-10-72-72-c253.corp.yahoo.com [10.72.72.253]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l01HLiUt001016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jan 2007 09:21:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=P3G0YM95lVND4dcVC2s8s/Xt8B3JL5Qa052AK/qQOI5FGcPeKi0C8E+pMJbEOfy9 Message-ID: <45994327.30306@yahoo-inc.com> Date: Mon, 01 Jan 2007 09:21:43 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Security and nationality References: <20061228103100.GA5181@generic-nic.net> <45940AF5.8010506@yahoo-inc.com> <45944F16.4C32@xyzzy.claranet.de> In-Reply-To: <45944F16.4C32@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> -- >> Languages and language variations are often closely associated with >> specific social, national, or ethnic affinities. Thus, language tags >> used in content negotiation, like other information exchanged on the >> Internet, might be a source of concern because they might be used to >> infer information about the sender and thus identify potential targets >> for surveillance. >> -- > > Okay. Jukka's proposal is also fine (maybe a bit long). I like the > keyword "private" in Stephane's version (Jukka has "personal", you've > only "information"). > One's language preference in a request header is hardly "private" information. The whole point of having an Accept-Language header is sharing that information in requests. "Personal" is probably better in this context. If we modify my paragraph to say "... infer personal information...", would that fix it? Or do you think that some other instance of "information" is the problem? Also, should we note that highly idiosyncratic Language Preference Lists (to use the 4647 term) might act as a signature for the user? Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 02 17:17:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rwU-0001RM-E9; Tue, 02 Jan 2007 17:17:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rwT-0001P2-5E for ltru@ietf.org; Tue, 02 Jan 2007 17:17:09 -0500 Received: from netc-relay-3m.netcourrier.com ([194.158.104.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1rwR-0004ej-A2 for ltru@ietf.org; Tue, 02 Jan 2007 17:17:09 -0500 Received: from netcourrier.com (netcourrier-4m.netcourrier.com [194.158.104.104]) by netc-relay-3m.netcourrier.com (Postfix) with SMTP id 2221F34419 for ; Tue, 2 Jan 2007 23:16:56 +0100 (CET) Received: from [85.68.10.110] by netcourrier-4m.netcourrier.com via html interface From: Nicolas Krebs To: ltru@ietf.org Subject: Re: [Ltru] Security and nationality Date: Tue, 2 Jan 2007 23:16:55 +0100 Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org >Date: Thu, 28 Dec 2006 13:46:52 +0200 (EET) >From: =22Jukka K. Korpela=22 >To: ltru=40ietf.org A little off topic, on Accept-Language header: = >In the so-called real world, we also have poorly written software that = >does very nasty things at times. In particular, the Thunderbird email = >program, following an old Netscape/Mozilla tradition, automatically = >inserts an X-Accept-Language header, with values taken from the settings = >in the Mozilla/Firefox web browser. It even includes that header into = >Usenet postings. Thus, information intended for selecting between = >different language versions of web pages is thereby sent, without = >informing the user, in all outgoing email and Usenet messages. This is of= = >course all wrong, but it's probably not formally wrong by any = >specification. - http://www.cs.tut.fi/=7Ejkorpela/headers.html=23X-Accept-Language = - RFC 4021 section 2.1.27 http://www.ietf.org/rfc/rfc4021.txt = http://tools.ietf.org/html/rfc4021=23section-2.1.27 - news:448bd88f=240=24163=24a3f2974a=40nnrp1.numericable.fr http://groups.google.com/group/fr.comp.mail/msg/aee199862e8e1a56 - http://bugzilla.mozilla.org/show=5Fbug.cgi?id=3D234033=23c47 - http://www.w3.org/International/questions/qa-lang-priorities _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 02 17:24:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1s3r-0006NH-DE; Tue, 02 Jan 2007 17:24:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1s3q-0006Lo-O0 for ltru@ietf.org; Tue, 02 Jan 2007 17:24:46 -0500 Received: from netc-relay-2m.netcourrier.com ([194.158.104.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1s1T-0005Ex-Er for ltru@ietf.org; Tue, 02 Jan 2007 17:22:21 -0500 Received: from netcourrier.com (netcourrier-4m.netcourrier.com [194.158.104.104]) by netc-relay-2m.netcourrier.com (Postfix) with SMTP id 6106126B84 for ; Tue, 2 Jan 2007 23:22:18 +0100 (CET) Received: from [85.68.10.110] by netcourrier-4m.netcourrier.com via html interface From: Nicolas Krebs To: ltru@ietf.org Subject: Re: [Ltru] Re: two identical singleton extension tags issue Date: Tue, 2 Jan 2007 23:22:17 +0100 Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org >Date: Thu, 21 Dec 2006 10:15:43 +0100 >From: Stephane Bortzmeyer >To: John Cowan >Copy: LTRU Working Group >On Wed, Dec 20, 2006 at 12:02:11PM -0500, > John Cowan wrote = > a message of 24 lines which said: > >> What is more, we should publish the regex in 4646bis = > >-1 > >Or even -X with X >> 1 :-) > >We publish the ABNF, which is the normative definition of the >grammar. Publishing the grammar in yet another format is a recipe for >subtle inconsistencies between them. Could it be INFORMATIVE, such in rfc 4287 Appendix B ? = >> so that people can use it in declarative contexts like XML schemas. > >May be we could suggest a very simplified regexp such as: > >=5Ba-z0-9=5D+(-=5Ba-z0-9=5D+)* = > >(case-insensitive, /i in Perl, re.IGNORECASE in Python) > >It would catch most of the stupid mistakes in XML files and be >reasonable readable, although more lax than the real grammar. in the >same way that the XML schema of RFC 4287 suggests the following regexp >for e-mail addresses (whose grammar is beyond the ability of 99.9 % of >mortal programmers): > > =23 Whatever an email address is, it contains at least one =40 > atomEmailAddress =3D xsd:string =7B pattern =3D =22.+=40.+=22 =7D If a very simplified regexp is added, i would suggest to add the following simplified ABNF as informative : = Language-Tag =3D 1*8ALPHA *( =22-=22 1*8alphanum ) (this would solve the issue = http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/=23i13 = for rfc 2616bis) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 02 19:27:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1txx-0001Av-JT; Tue, 02 Jan 2007 19:26:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1txv-000154-KN for ltru@ietf.org; Tue, 02 Jan 2007 19:26:47 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1txu-0002Ps-6x for ltru@ietf.org; Tue, 02 Jan 2007 19:26:47 -0500 Received: from [10.72.72.34] (snvvpn1-10-72-72-c34.corp.yahoo.com [10.72.72.34]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l030Qaj7081633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jan 2007 16:26:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=e+qkl1D6yyCZ/hd5xGwGp5bBd6ixmfyk7wWpd23l1C8aHOom64+IuYWiIu8fbLO+ Message-ID: <459AF83C.1030800@yahoo-inc.com> Date: Tue, 02 Jan 2007 16:26:36 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Nicolas Krebs Subject: Re: [Ltru] Security and nationality References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org It might not have occurred to you, but mailers might use this information to send bounce, error, and other messages in the language that the user prefers. Interestingly, it can also help mail servers determine the mail encoding for those messages that arrive unlabeled (any hint is better than none at all). Addison Nicolas Krebs wrote: >> Date: Thu, 28 Dec 2006 13:46:52 +0200 (EET) >> From: "Jukka K. Korpela" >> To: ltru@ietf.org > > A little off topic, on Accept-Language header: > >> In the so-called real world, we also have poorly written software that >> does very nasty things at times. In particular, the Thunderbird email >> program, following an old Netscape/Mozilla tradition, automatically >> inserts an X-Accept-Language header, with values taken from the settings >> in the Mozilla/Firefox web browser. It even includes that header into >> Usenet postings. Thus, information intended for selecting between >> different language versions of web pages is thereby sent, without >> informing the user, in all outgoing email and Usenet messages. This is of >> course all wrong, but it's probably not formally wrong by any >> specification. > > - http://www.cs.tut.fi/~jkorpela/headers.html#X-Accept-Language > - RFC 4021 section 2.1.27 http://www.ietf.org/rfc/rfc4021.txt > http://tools.ietf.org/html/rfc4021#section-2.1.27 > - news:448bd88f$0$163$a3f2974a@nnrp1.numericable.fr > http://groups.google.com/group/fr.comp.mail/msg/aee199862e8e1a56 > - http://bugzilla.mozilla.org/show_bug.cgi?id=234033#c47 > - http://www.w3.org/International/questions/qa-lang-priorities > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 03 14:16:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2BbU-0002VP-2i; Wed, 03 Jan 2007 14:16:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2BbT-0002VA-3e for ltru@ietf.org; Wed, 03 Jan 2007 14:16:47 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2BbR-0005LS-R2 for ltru@ietf.org; Wed, 03 Jan 2007 14:16:47 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070103191645.JOEC5532.mta11.adelphia.net@DGBP7M81> for ; Wed, 3 Jan 2007 14:16:45 -0500 Message-ID: <00f901c72f6b$b56ca1b0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 3 Jan 2007 11:16:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ltru] Unresolved issues for draft-4645bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Now that the holidays are over and many people have returned from e-mail hiatus, I'd really like to see the following issues resolved: 1. Decide how the new Registry, as initialized by RFC 4645bis, should handle inverted names: a. Use only the uninverted names from ISO 639-3 b. Use only the inverted names from ISO 639-3 c. Use all names from ISO 639-3 d. Some other possibility 2. Decide, based on which option above is chosen, whether any corresponding changes need to be made in the region subtags, some of which have a single Description in inverted form. 2. Determine whether everyone is satisfied with the current wording in draft-4646bis-02, Section 3.1.4 about the first of multiple "Description" fields corresponding to the ISO 639-3 Reference Name, or whether there is still a desire for a discrete "Reference-Name" field. These issues MUST all be resolved before I can prepare a new draft-4645bis-01. The deadline for this draft to go to IETF Last Call -- not just WG Last Call -- is 29 days away, so we should resolve them soon. I ask the co-chairs to help gauge the hum of the WG. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 03 15:27:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Chi-0007L7-0j; Wed, 03 Jan 2007 15:27:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Chg-0007Jg-8j for ltru@ietf.org; Wed, 03 Jan 2007 15:27:16 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Che-00012s-TJ for ltru@ietf.org; Wed, 03 Jan 2007 15:27:16 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l03KR3aG040770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 12:27:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=VJawArX0+ytTrBMu9ZLORH+AHfulHqEsgeuo61Xi43xgxxG5olmCZ8+E4x9cyaCw Message-ID: <459C1197.80100@yahoo-inc.com> Date: Wed, 03 Jan 2007 12:27:03 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Unresolved issues for draft-4645bis References: <00f901c72f6b$b56ca1b0$6501a8c0@DGBP7M81> In-Reply-To: <00f901c72f6b$b56ca1b0$6501a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Now that the holidays are over and many people have returned from e-mail > hiatus, I'd really like to see the following issues resolved: > > 1. Decide how the new Registry, as initialized by RFC 4645bis, should > handle inverted names: > > a. Use only the uninverted names from ISO 639-3 > b. Use only the inverted names from ISO 639-3 > c. Use all names from ISO 639-3 > d. Some other possibility I think (c) is the most reasonable solution. Why should we get into the business of choosing and editing the names at initial registration? The more we dabble with this, the more I favor following ISO 639. > > 2. Decide, based on which option above is chosen, whether any > corresponding changes need to be made in the region subtags, some of > which have a single Description in inverted form. ... which choice obviates this problem. > > 2. Determine whether everyone is satisfied with the current wording in > draft-4646bis-02, Section 3.1.4 about the first of multiple > "Description" fields corresponding to the ISO 639-3 Reference Name, or > whether there is still a desire for a discrete "Reference-Name" field. I think "Reference-Name" as a field is a bad idea. I'm happy to make the first name that appears in a Description field "turn out" to be the Reference Name. In which case, I think it should *exactly* match the reference name, (un)inversions and all. I think that this should also be extended to all ISO based records, not just language/extlangs. (I think this is mostly the case anyway.) > > These issues MUST all be resolved before I can prepare a new > draft-4645bis-01. The deadline for this draft to go to IETF Last Call > -- not just WG Last Call -- is 29 days away, so we should resolve them > soon. I ask the co-chairs to help gauge the hum of the WG. Why MUST all of these be resolved first? It's a draft. There are still many integers available after "-01". It's unfortunate that we won't have everything resolved, but it would give us something to look at if you pick one of the options and make the draft look that way. WRT the charter deadline, note that we rely on ISO 639-3 being published before *any* Last Calls can take place. I note that, at least this morning, ISO lists 639-3:2007 as status "60.00" (which is "International Standard under publication", the last step before publication). Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 03 16:07:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2D8X-0001nK-T9; Wed, 03 Jan 2007 15:55:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2D8R-0001jp-0K for ltru@ietf.org; Wed, 03 Jan 2007 15:54:55 -0500 Received: from mta16.mail.adelphia.net ([68.168.78.211] helo=mta16.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2D83-0005y8-Fl for ltru@ietf.org; Wed, 03 Jan 2007 15:54:54 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070103203806.YUJV2311.mta16.adelphia.net@DGBP7M81>; Wed, 3 Jan 2007 15:38:06 -0500 Message-ID: <00fd01c72f79$5b39a040$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00f901c72f6b$b56ca1b0$6501a8c0@DGBP7M81> <459C1197.80100@yahoo-inc.com> Subject: Re: [Ltru] Unresolved issues for draft-4645bis Date: Wed, 3 Jan 2007 12:54:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> a. Use only the uninverted names from ISO 639-3 >> b. Use only the inverted names from ISO 639-3 >> c. Use all names from ISO 639-3 >> d. Some other possibility > > I think (c) is the most reasonable solution. Why should we get into > the business of choosing and editing the names at initial > registration? The more we dabble with this, the more I favor following > ISO 639. Great, and I do not disagree (although that does require a change to the first paragraph of draft-4646bis-02, Section 3.1.4). What do others think? BTW, for those who are deciding, there are approximately 1,400 inverted forms in ISO/FDIS 639-3. The overall size impact of adding these to the Registry is not great. > I think "Reference-Name" as a field is a bad idea. I'm happy to make > the first name that appears in a Description field "turn out" to be > the Reference Name. In which case, I think it should *exactly* match > the reference name, (un)inversions and all. Great, and I do not disagree. What do others think? > I think that this should also be extended to all ISO based records, > not just language/extlangs. (I think this is mostly the case anyway.) ISO 15924 puts alternative names in parentheses, in a comma-separated list: Han (Hanzi, Kanji, Hanja) These are currently copied verbatim into the Registry, with no post-processing. If we are going to change that, we should decide now. ISO 3166, or at least the freely available list of names on their Web site, provides no alternative forms. Neither does UN M.49, although it should be pointed out that UNSD does not appear to treat M.49 as a "standard" in the formal ISO sense. > Why MUST all of these be resolved first? It's a draft. There are still > many integers available after "-01". It's unfortunate that we won't > have everything resolved, but it would give us something to look at if > you pick one of the options and make the draft look that way. I'll quote from my post of December 15: "On several occasions, I've been asked to simply pick one of these options, write the draft, and wait for feedback. The reason I haven't done this is that it's not just about writing the draft. RFC 4645bis -- like RFC 4645 but on a much larger scale -- requires the generations of hundreds of pages of data that reflect the decisions specified in the prose. Because of the size of this project, I would greatly prefer to write a program to generate the new Registry data from the ISO 639-3 files and the existing Registry, rather than attempting to do it by hand. Changing a decision like this would require modifying the program and validating the results before submitting a new draft. The cost of submitting a draft that is out of touch with the WG is high." The supply of integers doesn't matter to me; repeatedly rewriting my program to generate the output does. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 03 16:32:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Dif-0005BK-13; Wed, 03 Jan 2007 16:32:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Die-0005AJ-F8 for ltru@ietf.org; Wed, 03 Jan 2007 16:32:20 -0500 Received: from mta16.mail.adelphia.net ([68.168.78.211] helo=mta16.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Did-0004Px-4f for ltru@ietf.org; Wed, 03 Jan 2007 16:32:20 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070103211554.BVCF2311.mta16.adelphia.net@DGBP7M81> for ; Wed, 3 Jan 2007 16:15:54 -0500 Message-ID: <010901c72f7e$a2fe5470$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 3 Jan 2007 13:32:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Re: Well-formed vs. regular (Was: I-D ACTION:draft-ietf-ltru-4646bis-01.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> This is not perfect yet in -02 which says: >> >> grandfathered = langtag ; well-formed grandfathered tags >> / irregular ; grandfathered that don't match langtag >> >> The "well-formed" should be replaced by "regular". > > Except that "regular" doesn't really convey any information here. Yes, > it is an antonym for 'irregular', but that doesn't really add > information. I think we should just omit "well-formed". I agree. This would define "langtag" and "regular" circularly, in terms of each other, much like writing: grandfathered = A ; grandfathered tags that aren't B / B ; grandfathered tags that aren't A Are the comments really necessary at all, or are the definitions of "langtag" and "irregular" sufficient (or even better) on their own? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 03 17:25:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2EXf-0004sk-Pz; Wed, 03 Jan 2007 17:25:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2EXe-0004sL-Uv for ltru@ietf.org; Wed, 03 Jan 2007 17:25:02 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2EXc-0007iU-NX for ltru@ietf.org; Wed, 03 Jan 2007 17:25:02 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H2EXU-0007xg-1B for ltru@ietf.org; Wed, 03 Jan 2007 17:24:52 -0500 Date: Wed, 3 Jan 2007 17:24:52 -0500 To: ltru@ietf.org Message-ID: <20070103222451.GA5718@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] Definition of "grandfathered" considered lame X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org In the ABNF in 4646bis-02, a Language-Tag (the root production) can be a langtag, a privateuse, or a grandfathered. But a grandfathered can be a langtag or an irregular. Consequently, the grammar is technically ambiguous. I propose that the Language-Tag production be changed to refer to irregular directly rather than grandfathered. The grandfathered production needs to be kept because there is a reference to it in 3.1.2. On the editorial side, the term "well-formed tag" is not really defined anywhere. It should be defined in one place and then used. This would be improved by not talking about "well-formed processors", but rather about "non-validating processors", which is what is meant. -- A rabbi whose congregation doesn't want John Cowan to drive him out of town isn't a rabbi, http://www.ccil.org/~cowan and a rabbi who lets them do it cowan@ccil.org isn't a man. --Jewish saying _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 03 17:37:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2EjD-0003Tc-FV; Wed, 03 Jan 2007 17:36:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2EjC-0003TR-Iw for ltru@ietf.org; Wed, 03 Jan 2007 17:36:58 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2EjB-0002DH-9X for ltru@ietf.org; Wed, 03 Jan 2007 17:36:58 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H2EjA-0008Qd-UO; Wed, 03 Jan 2007 17:36:56 -0500 Date: Wed, 3 Jan 2007 17:36:56 -0500 To: Doug Ewell Subject: Re: [Ltru] Unresolved issues for draft-4645bis Message-ID: <20070103223656.GB5718@ccil.org> References: <00f901c72f6b$b56ca1b0$6501a8c0@DGBP7M81> <459C1197.80100@yahoo-inc.com> <00fd01c72f79$5b39a040$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00fd01c72f79$5b39a040$6501a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > >I think (c) is the most reasonable solution. Why should we get into > >the business of choosing and editing the names at initial > >registration? The more we dabble with this, the more I favor following > >ISO 639. > > Great, and I do not disagree (although that does require a change to the > first paragraph of draft-4646bis-02, Section 3.1.4). What do others > think? I reluctantly agree. The names are a mess, and we might as well capture all that we can, as it may help somebody. > >I think "Reference-Name" as a field is a bad idea. I'm happy to make > >the first name that appears in a Description field "turn out" to be > >the Reference Name. In which case, I think it should *exactly* match > >the reference name, (un)inversions and all. > > Great, and I do not disagree. What do others think? In the ISO 639 world, only the entries in 639-3 have a reference name. In particular, the language-collection codes of 639-2 are not replicated in 639-3 and have no reference names. I don't care how you sort the fields, but I am very much against giving guarantees about the order of Description fields in 4646bis. You'd have to say "The first Description field is the reference name provided by the standard, if it provides one at all." Since we do not document which subtags come from which standards, this is of very little use. > ISO 15924 puts alternative names in parentheses, in a comma-separated > list: > > Han (Hanzi, Kanji, Hanja) We should break these up. They are definitely alternative names. > ISO 3166, or at least the freely available list of names on their Web > site, provides no alternative forms. Neither does UN M.49, although it > should be pointed out that UNSD does not appear to treat M.49 as a > "standard" in the formal ISO sense. Neither of these provide anything comparable to a reference name: the names are simply customary, with no legal force. (The long names, which may have legal force in some countries, are not provided freely.) -- A: "Spiro conjectures Ex-Lax." John Cowan Q: "What does Pat Nixon frost her cakes with?" cowan@ccil.org --"Jeopardy" for generative semanticists http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 03 17:37:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ejt-0003el-Q7; Wed, 03 Jan 2007 17:37:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ejs-0003eP-Hc for ltru@ietf.org; Wed, 03 Jan 2007 17:37:40 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Ejr-0002Ut-Av for ltru@ietf.org; Wed, 03 Jan 2007 17:37:40 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H2Ejr-0008Sl-27; Wed, 03 Jan 2007 17:37:39 -0500 Date: Wed, 3 Jan 2007 17:37:39 -0500 To: Doug Ewell Subject: Re: [Ltru] Re: Well-formed vs. regular (Was: I-D ACTION:draft-ietf-ltru-4646bis-01.txt Message-ID: <20070103223739.GC5718@ccil.org> References: <010901c72f7e$a2fe5470$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010901c72f7e$a2fe5470$6501a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Are the comments really necessary at all, or are the definitions of > "langtag" and "irregular" sufficient (or even better) on their own? Lose the comments, I'd say. See also my earlier posting. -- Even a refrigerator can conform to the XML John Cowan Infoset, as long as it has a door sticker cowan@ccil.org saying "No information items inside". http://www.ccil.org/~cowan --Eve Maler _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 03 17:52:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Exq-0003rV-8H; Wed, 03 Jan 2007 17:52:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Exp-0003rQ-75 for ltru@ietf.org; Wed, 03 Jan 2007 17:52:05 -0500 Received: from an-out-0708.google.com ([209.85.132.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2Exm-0003jw-M8 for ltru@ietf.org; Wed, 03 Jan 2007 17:52:05 -0500 Received: by an-out-0708.google.com with SMTP id d30so2024584and for ; Wed, 03 Jan 2007 14:52:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=AX0uC1rEPvwO2OUfs6WHXS8R74+18BW/lx9a4eh/C6cV3h/y0mz1rtmpMoB32KWzb28PK9fNUG5dbYT1h5ksEi9GhiCi1CUaAdbXlQYaLGJYgW/jaiEfuU2/oBNNyF9ot0doWZrwvzuhhs5PL5A3+JsJkgkMhxYTbeRGGi7pJx4= Received: by 10.100.42.7 with SMTP id p7mr6971243anp.1167864721220; Wed, 03 Jan 2007 14:52:01 -0800 (PST) Received: by 10.100.37.12 with HTTP; Wed, 3 Jan 2007 14:52:01 -0800 (PST) Message-ID: <30b660a20701031452u123a50dp3718f656926b36c2@mail.gmail.com> Date: Wed, 3 Jan 2007 14:52:01 -0800 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Unresolved issues for draft-4645bis In-Reply-To: <20070103223656.GB5718@ccil.org> MIME-Version: 1.0 References: <00f901c72f6b$b56ca1b0$6501a8c0@DGBP7M81> <459C1197.80100@yahoo-inc.com> <00fd01c72f79$5b39a040$6501a8c0@DGBP7M81> <20070103223656.GB5718@ccil.org> X-Google-Sender-Auth: fa580db5fb93acf5 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1603644451==" Errors-To: ltru-bounces@ietf.org --===============1603644451== Content-Type: multipart/alternative; boundary="----=_Part_18595_2792622.1167864721199" ------=_Part_18595_2792622.1167864721199 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 1/3/07, John Cowan wrote: > > Doug Ewell scripsit: > > > >I think (c) is the most reasonable solution. Why should we get into > > >the business of choosing and editing the names at initial > > >registration? The more we dabble with this, the more I favor following > > >ISO 639. > > > > Great, and I do not disagree (although that does require a change to the > > first paragraph of draft-4646bis-02, Section 3.1.4). What do others > > think? > > I reluctantly agree. The names are a mess, and we might as well capture > all that we can, as it may help somebody. > > > >I think "Reference-Name" as a field is a bad idea. I'm happy to make > > >the first name that appears in a Description field "turn out" to be > > >the Reference Name. In which case, I think it should *exactly* match > > >the reference name, (un)inversions and all. > > > > Great, and I do not disagree. What do others think? > > In the ISO 639 world, only the entries in 639-3 have a reference name. > In particular, the language-collection codes of 639-2 are not replicated > in 639-3 and have no reference names. I don't care how you sort the > fields, but I am very much against giving guarantees about the order of > Description fields in 4646bis. You'd have to say "The first Description > field is the reference name provided by the standard, if it provides > one at all." Since we do not document which subtags come from which > standards, this is of very little use. You've made it quite clear that it is of little use to you. It is of great use to us, and little cost to you. > ISO 15924 puts alternative names in parentheses, in a comma-separated > > list: > > > > Han (Hanzi, Kanji, Hanja) > > We should break these up. They are definitely alternative names. yes > ISO 3166, or at least the freely available list of names on their Web > > site, provides no alternative forms. Neither does UN M.49, although it > > should be pointed out that UNSD does not appear to treat M.49 as a > > "standard" in the formal ISO sense. > > Neither of these provide anything comparable to a reference name: the > names > are simply customary, with no legal force. (The long names, which may > have > legal force in some countries, are not provided freely.) We have collected alternative names that are used by the World Bank and others. It might be worth adding, but that topic is orthogonal to the one at hand. -- > A: "Spiro conjectures Ex-Lax." John Cowan > Q: "What does Pat Nixon frost her cakes with?" cowan@ccil.org > --"Jeopardy" for generative semanticists http://www.ccil.org/~cowan > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_18595_2792622.1167864721199 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 1/3/07, John Cowan <cowan@ccil.org> wrote:
Doug Ewell scripsit:

> >I think (c) is the most reasonable solution. Why should we get into
> >the business of choosing and editing the names at initial
> >registration? The more we dabble with this, the more I favor following
> >ISO 639.
>
> Great, and I do not disagree (although that does require a change to the
> first paragraph of draft-4646bis-02, Section 3.1.4).  What do others
> think?

I reluctantly agree.  The names are a mess, and we might as well capture
all that we can, as it may help somebody.

> >I think "Reference-Name" as a field is a bad idea. I'm happy to make
> >the first name that appears in a Description field "turn out" to be
> >the Reference Name. In which case, I think it should *exactly* match
> >the reference name, (un)inversions and all.
>
> Great, and I do not disagree.  What do others think?

In the ISO 639 world, only the entries in 639-3 have a reference name.
In particular, the language-collection codes of 639-2 are not replicated
in 639-3 and have no reference names.  I don't care how you sort the
fields, but I am very much against giving guarantees about the order of
Description fields in 4646bis.  You'd have to say "The first Description
field is the reference name provided by the standard, if it provides
one at all."  Since we do not document which subtags come from which
standards, this is of very little use.

You've made it quite clear that it is of little use to you. It is of great use to us, and little cost to you.

> ISO 15924 puts alternative names in parentheses, in a comma-separated
> list:
>
>    Han (Hanzi, Kanji, Hanja)

We should break these up.  They are definitely alternative names.

yes

> ISO 3166, or at least the freely available list of names on their Web
> site, provides no alternative forms.  Neither does UN M.49, although it
> should be pointed out that UNSD does not appear to treat M.49 as a
> "standard" in the formal ISO sense.

Neither of these provide anything comparable to a reference name: the names
are simply customary, with no legal force.  (The long names, which may have
legal force in some countries, are not provided freely.)

We have collected alternative names that are used by the World Bank and others. It might be worth adding, but that topic is orthogonal to the one at hand.

--
A: "Spiro conjectures Ex-Lax."                  John Cowan
Q: "What does Pat Nixon frost her cakes with?"  cowan@ccil.org
  --"Jeopardy" for generative semanticists      http://www.ccil.org/~cowan

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



--
Mark ------=_Part_18595_2792622.1167864721199-- --===============1603644451== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1603644451==-- From ltru-bounces@ietf.org Wed Jan 03 17:56:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2F1u-0005qf-1p; Wed, 03 Jan 2007 17:56:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2F1s-0005qD-Ct for ltru@ietf.org; Wed, 03 Jan 2007 17:56:16 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2F1r-0006UN-2D for ltru@ietf.org; Wed, 03 Jan 2007 17:56:16 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l03MtqHY050682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 14:55:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=kIyQoylcza8/mWGFV3GOnTmePDRMu/DuYZ9SWDaZ8d36htLZz4ZLw/G0/wGxFWkn Message-ID: <459C3478.1090400@yahoo-inc.com> Date: Wed, 03 Jan 2007 14:55:52 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Definition of "grandfathered" considered lame References: <20070103222451.GA5718@ccil.org> In-Reply-To: <20070103222451.GA5718@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > In the ABNF in 4646bis-02, a Language-Tag (the root production) can be > a langtag, a privateuse, or a grandfathered. But a grandfathered can > be a langtag or an irregular. Consequently, the grammar is technically > ambiguous. > > I propose that the Language-Tag production be changed to refer to > irregular directly rather than grandfathered. The grandfathered > production needs to be kept because there is a reference to it in 3.1.2. I appreciate the point, yet I'm reluctant to make the change. I think it useful "self-commentary" to have 'grandfathered' appear in the Language-Tag production. A better alternative would be: - List both the regular and irregular sets. If my count is correct, the 'regular' list has only 11 items in it in the 4646bis era. We can separately note that all of these items match the langtag production, which is what makes them 'regular'. > > On the editorial side, the term "well-formed tag" is not really defined > anywhere. It should be defined in one place and then used. This would > be improved by not talking about "well-formed processors", but rather > about "non-validating processors", which is what is meant. > Not quite. There are *three* classes of conformance (two defined, and one undefined): validating, well-formed, and "everything else". I agree that referencing "well-formed" in the ANBF is a bit out of whack, since we were careful to make "well-formed" and "validating" classes of conformance elsewhere. But the "well-formed tag" thing is problematic if we really mean the langtag production and not the Language-Tag production. This can be cleaned up by making the change I propose above and then referencing Language-Tag as synonymous with "well-formed". Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 03 18:19:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2FOV-0002po-AV; Wed, 03 Jan 2007 18:19:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2FOU-0002ph-8j for ltru@ietf.org; Wed, 03 Jan 2007 18:19:38 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2FOR-0003gh-EH for ltru@ietf.org; Wed, 03 Jan 2007 18:19:38 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H2FOQ-0003cs-Q7; Wed, 03 Jan 2007 18:19:34 -0500 Date: Wed, 3 Jan 2007 18:19:34 -0500 To: Mark Davis Subject: Re: [Ltru] Unresolved issues for draft-4645bis Message-ID: <20070103231934.GD5718@ccil.org> References: <00f901c72f6b$b56ca1b0$6501a8c0@DGBP7M81> <459C1197.80100@yahoo-inc.com> <00fd01c72f79$5b39a040$6501a8c0@DGBP7M81> <20070103223656.GB5718@ccil.org> <30b660a20701031452u123a50dp3718f656926b36c2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20701031452u123a50dp3718f656926b36c2@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > >You'd have to say "The first Description > >field is the reference name provided by the standard, if it provides > >one at all." Since we do not document which subtags come from which > >standards, this is of very little use. > > You've made it quite clear that it is of little use to you. It is of great > use to us, and little cost to you. Not what I meant. What can you do with the standards language above? It's equivalent to "The first name MAY be the reference name; second and later names MUST NOT be the reference name." What good is that? You can't count on getting a reference name from the registry because there may not be one. > We have collected alternative names that are used by the World Bank and > others. It might be worth adding, but that topic is orthogonal to the one at > hand. -1 There is an unbounded amount of encyclopedic information we could add to the registry. Going outside the domain of the source standards, where do you stop? -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory that the mongoose first came to India on a raft from Polynesia. --blurb for Rikki-Kon-Tiki-Tavi _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 03 18:27:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2FWC-00085A-Or; Wed, 03 Jan 2007 18:27:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2FWB-000854-GJ for ltru@ietf.org; Wed, 03 Jan 2007 18:27:35 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2FWA-0005ZC-8a for ltru@ietf.org; Wed, 03 Jan 2007 18:27:35 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H2FW9-0004tP-I7; Wed, 03 Jan 2007 18:27:33 -0500 Date: Wed, 3 Jan 2007 18:27:33 -0500 To: Addison Phillips Subject: Re: [Ltru] Definition of "grandfathered" considered lame Message-ID: <20070103232733.GE5718@ccil.org> References: <20070103222451.GA5718@ccil.org> <459C3478.1090400@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <459C3478.1090400@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > - List both the regular and irregular sets. If my count is correct, the > 'regular' list has only 11 items in it in the 4646bis era. We can > separately note that all of these items match the langtag production, > which is what makes them 'regular'. The irregular set can't shrink, though. The regular set can, if we register subtags like boont. (I tried, but Michael refused.) What's more, it doesn't solve the problem I'm complaining about, which is that some tags will be able to match the ABNF is more than one way. > I agree that referencing "well-formed" in the ANBF is a bit out of > whack, since we were careful to make "well-formed" and "validating" > classes of conformance elsewhere. Actually not. Look at 2.2.6 bullet 3, and 2.2.8 graf 1, and the first requirement of validating processors in 2.2.9, and 4.4 bullet 1, and the example in 4.4. > But the "well-formed tag" thing is problematic if we really mean the > langtag production and not the Language-Tag production. This can be > cleaned up by making the change I propose above and then referencing > Language-Tag as synonymous with "well-formed". I agree; "well-formed" should mean "matches the ABNF" and nothing else. That way, non-validating processors MUST check that the tag is well-formed and SHOULD check that there are no duplicate singletons. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org 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@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 03 20:29:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HPh-0002YE-42; Wed, 03 Jan 2007 20:29:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HPf-0002Wt-S8 for ltru@ietf.org; Wed, 03 Jan 2007 20:28:59 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2HPd-00082u-7k for ltru@ietf.org; Wed, 03 Jan 2007 20:28:58 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070104012856.KDTC20139.mta9.adelphia.net@DGBP7M81>; Wed, 3 Jan 2007 20:28:56 -0500 Message-ID: <013701c72f9f$b3d980f0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00f901c72f6b$b56ca1b0$6501a8c0@DGBP7M81> <459C1197.80100@yahoo-inc.com> <00fd01c72f79$5b39a040$6501a8c0@DGBP7M81> <20070103223656.GB5718@ccil.org> Subject: Re: [Ltru] Unresolved issues for draft-4645bis Date: Wed, 3 Jan 2007 17:28:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > In the ISO 639 world, only the entries in 639-3 have a reference name. > In particular, the language-collection codes of 639-2 are not > replicated in 639-3 and have no reference names. I don't care how you > sort the fields, but I am very much against giving guarantees about > the order of Description fields in 4646bis. You'd have to say "The > first Description field is the reference name provided by the > standard, if it provides one at all." Since we do not document which > subtags come from which standards, this is of very little use. This is pretty much what draft-4646bis-02 says: "For fields of type 'language' or 'extlang', the first 'Description' field appearing in the Registry corresponds to the Reference Name assigned by ISO 639-3." It makes no claims about any other type of subtag, which is as it should be. The only flaw, as John said, is that the claim is made for language collections not included in 639-3. Whether there is a geniune problem here is left as an exercise. In the debate over the Reference-Name field, I suggested that (a) the new field should be omitted when there was only one Description, (b) this would leave it ambiguous whether an ISO reference name actually existed, and (c) this is likely not a problem. Perhaps the same is true here. >> ISO 15924 puts alternative names in parentheses, in a comma-separated >> list: >> >> Han (Hanzi, Kanji, Hanja) > > We should break these up. They are definitely alternative names. And Mark agreed. Naturally, this can't be simple: ISO 15924 uses parentheses for explanatory content as well as for alternative names. I guess we should split out the following: Devanagari (Nagari) Deseret (Mormon) Ethiopic (Geʻez) Ethiopic (Ge'ez) Hangul (Hangŭl, Hangeul) Han (Hanzi, Kanji, Hanja) Hanunoo (Hanunóo) Indus (Harappan) Lepcha (Róng) Myanmar (Burmese) Ol Chiki (Ol Cemet', Ol, Santali) Shavian (Shaw) Tifinagh (Berber) and leave the following alone: Cyrillic (Old Church Slavonic variant) Khutsuri (Asomtavruli and Nuskhuri) Georgian (Mkhedruli) Han (Simplified variant) Han (Traditional variant) (alias for Hiragana + Katakana) Old Italic (Etruscan, Oscan, etc.) Japanese (alias for Han + Hiragana + Katakana) Latin (Fraktur variant) Latin (Gaelic variant) Syriac (Estrangelo variant) Syriac (Western variant) Syriac (Eastern variant) but others may disagree, and I need to know what to go with. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 03 20:33:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HTj-0004je-Ma; Wed, 03 Jan 2007 20:33:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HTi-0004jY-KG for ltru@ietf.org; Wed, 03 Jan 2007 20:33:10 -0500 Received: from an-out-0708.google.com ([209.85.132.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2HTh-0000C7-8L for ltru@ietf.org; Wed, 03 Jan 2007 20:33:10 -0500 Received: by an-out-0708.google.com with SMTP id d30so2035646and for ; Wed, 03 Jan 2007 17:33:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=HVksZnpdXb95JMA3h5USYeTyWAjlEg27pdi/kI6qL8sYJdKf0klKa3NhiE1VaXBvaDdLp7nHj8RSxJLWprmvjd8mGxjavGk1zItb52UyCIILc91wxGVvNb66pGPsB5ac7p8tJEf0JrzrvERgJT+hLOT5rluXEdyF8Ny5N2KLhkc= Received: by 10.100.119.14 with SMTP id r14mr7056896anc.1167874389020; Wed, 03 Jan 2007 17:33:09 -0800 (PST) Received: by 10.100.37.12 with HTTP; Wed, 3 Jan 2007 17:33:09 -0800 (PST) Message-ID: <30b660a20701031733j117aa9beibb2424804a4188e3@mail.gmail.com> Date: Wed, 3 Jan 2007 17:33:09 -0800 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Definition of "grandfathered" considered lame In-Reply-To: <20070103232733.GE5718@ccil.org> MIME-Version: 1.0 References: <20070103222451.GA5718@ccil.org> <459C3478.1090400@yahoo-inc.com> <20070103232733.GE5718@ccil.org> X-Google-Sender-Auth: 42c5cd132bfe9522 X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1311870938==" Errors-To: ltru-bounces@ietf.org --===============1311870938== Content-Type: multipart/alternative; boundary="----=_Part_25_2775292.1167874389001" ------=_Part_25_2775292.1167874389001 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 1/3/07, John Cowan wrote: > > Addison Phillips scripsit: > > > - List both the regular and irregular sets. If my count is correct, the > > 'regular' list has only 11 items in it in the 4646bis era. We can > > separately note that all of these items match the langtag production, > > which is what makes them 'regular'. > > The irregular set can't shrink, though. The regular set can, if > we register subtags like boont. (I tried, but Michael refused.) > What's more, it doesn't solve the problem I'm complaining about, which > is that some tags will be able to match the ABNF is more than one way. > > > I agree that referencing "well-formed" in the ANBF is a bit out of > > whack, since we were careful to make "well-formed" and "validating" > > classes of conformance elsewhere. > > Actually not. Look at 2.2.6 bullet 3, and 2.2.8 graf 1, and the > first requirement of validating processors in 2.2.9, and 4.4 bullet 1, > and the example in 4.4. > > > But the "well-formed tag" thing is problematic if we really mean the > > langtag production and not the Language-Tag production. This can be > > cleaned up by making the change I propose above and then referencing > > Language-Tag as synonymous with "well-formed". > > I agree; "well-formed" should mean "matches the ABNF" and nothing else. > That way, non-validating processors MUST check that the tag is well-formed > and SHOULD check that there are no duplicate singletons. Agreed -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > 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@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_25_2775292.1167874389001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 1/3/07, John Cowan <cowan@ccil.org> wrote:
Addison Phillips scripsit:

> - List both the regular and irregular sets. If my count is correct, the
> 'regular' list has only 11 items in it in the 4646bis era. We can
> separately note that all of these items match the langtag production,
> which is what makes them 'regular'.

The irregular set can't shrink, though.  The regular set can, if
we register subtags like boont.  (I tried, but Michael refused.)
What's more, it doesn't solve the problem I'm complaining about, which
is that some tags will be able to match the ABNF is more than one way.

> I agree that referencing "well-formed" in the ANBF is a bit out of
> whack, since we were careful to make "well-formed" and "validating"
> classes of conformance elsewhere.

Actually not.  Look at 2.2.6 bullet 3, and 2.2.8 graf 1, and the
first requirement of validating processors in 2.2.9, and 4.4 bullet 1,
and the example in 4.4.

> But the "well-formed tag" thing is problematic if we really mean the
> langtag production and not the Language-Tag production. This can be
> cleaned up by making the change I propose above and then referencing
> Language-Tag as synonymous with "well-formed".

I agree; "well-formed" should mean "matches the ABNF" and nothing else.
That way, non-validating processors MUST check that the tag is well-formed
and SHOULD check that there are no duplicate singletons.

Agreed

--
John Cowan      http://www.ccil.org/~cowan      cowan@ccil.org
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@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru



--
Mark ------=_Part_25_2775292.1167874389001-- --===============1311870938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1311870938==-- From ltru-bounces@ietf.org Wed Jan 03 20:56:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HqT-0000wm-Je; Wed, 03 Jan 2007 20:56:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HqR-0000w4-Qy for ltru@ietf.org; Wed, 03 Jan 2007 20:56:39 -0500 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2HqQ-0003Cz-Gy for ltru@ietf.org; Wed, 03 Jan 2007 20:56:39 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070104014506.KVSL25578.mta15.adelphia.net@DGBP7M81>; Wed, 3 Jan 2007 20:45:06 -0500 Message-ID: <014301c72fa3$92082310$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 3 Jan 2007 17:56:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: Definition of "grandfathered" considered lame X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > The irregular set can't shrink, though. The regular set can, if we > register subtags like boont. (I tried, but Michael refused.) No, he didn't: Type: variant Subtag: boont Description: Boontling Added: 2006-09-18 Prefix: en Comments: Jargon embedded in American English -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 03 21:52:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ii6-00070n-P2; Wed, 03 Jan 2007 21:52:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ii4-00070d-SK for ltru@ietf.org; Wed, 03 Jan 2007 21:52:04 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Ii3-0004r5-LM for ltru@ietf.org; Wed, 03 Jan 2007 21:52:04 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H2Ii3-00046t-1g; Wed, 03 Jan 2007 21:52:03 -0500 Date: Wed, 3 Jan 2007 21:52:02 -0500 To: Doug Ewell Message-ID: <20070104025202.GJ6453@ccil.org> References: <014301c72fa3$92082310$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <014301c72fa3$92082310$6501a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org Subject: [Ltru] Re: Definition of "grandfathered" considered lame X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > John Cowan wrote: > > >The irregular set can't shrink, though. The regular set can, if we > >register subtags like boont. (I tried, but Michael refused.) > > No, he didn't: My bad. Post in haste, repent at leisure. -- Is not a patron, my Lord [Chesterfield], John Cowan one who looks with unconcern on a man http://www.ccil.org/~cowan struggling for life in the water, and when cowan@ccil.org he has reached ground encumbers him with help? --Samuel Johnson _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 05 05:34:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mOh-0006P0-68; Fri, 05 Jan 2007 05:34:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mOf-0006Km-6s for ltru@ietf.org; Fri, 05 Jan 2007 05:34:01 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2mOX-0002Fy-3t for ltru@ietf.org; Fri, 05 Jan 2007 05:34:01 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l05AXkrW024064 for ; Fri, 5 Jan 2007 19:33:46 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0c41_38df64f2_9ca8_11db_8072_0014221fa3c9; Fri, 05 Jan 2007 19:33:45 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49968) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 5 Jan 2007 19:33:00 +0900 Message-Id: <6.0.0.20.2.20070105170143.02432570@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 05 Jan 2007 17:04:27 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Unresolved issues for draft-4645bis In-Reply-To: <013701c72f9f$b3d980f0$6501a8c0@DGBP7M81> References: <00f901c72f6b$b56ca1b0$6501a8c0@DGBP7M81> <459C1197.80100@yahoo-inc.com> <00fd01c72f79$5b39a040$6501a8c0@DGBP7M81> <20070103223656.GB5718@ccil.org> <013701c72f9f$b3d980f0$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Doug, At 10:28 07/01/04, Doug Ewell wrote: >John Cowan wrote: > >> In the ISO 639 world, only the entries in 639-3 have a reference name. In particular, the language-collection codes of 639-2 are not replicated in 639-3 and have no reference names. I don't care how you sort the fields, but I am very much against giving guarantees about the order of Description fields in 4646bis. You'd have to say "The first Description field is the reference name provided by the standard, if it provides one at all." Since we do not document which subtags come from which standards, this is of very little use. > >This is pretty much what draft-4646bis-02 says: > >"For fields of type 'language' or 'extlang', the first 'Description' field appearing in the Registry corresponds to the Reference Name assigned by ISO 639-3." > >It makes no claims about any other type of subtag, which is as it should be. The only flaw, as John said, is that the claim is made for language collections not included in 639-3. Whether there is a geniune problem here is left as an exercise. I think it would be good if your draft could be slightly more precise, i.e. say "For fields of type 'language' or 'extlang', the first 'Description' field appearing in the Registry corresponds to the Reference Name assigned by ISO 639-3 if this entry exists in ISO 639-3." (or some such) >Naturally, this can't be simple: ISO 15924 uses parentheses for explanatory content as well as for alternative names. I guess we should split out the following: >and leave the following alone: > >Cyrillic (Old Church Slavonic variant) >Khutsuri (Asomtavruli and Nuskhuri) >Georgian (Mkhedruli) >Han (Simplified variant) >Han (Traditional variant) >(alias for Hiragana + Katakana) Why doesn't this read Kana (alias for Hiragana + Katakana) ? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 05 10:05:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qdL-0003VF-0N; Fri, 05 Jan 2007 10:05:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qdK-0003VA-EI for ltru@ietf.org; Fri, 05 Jan 2007 10:05:26 -0500 Received: from mta16.mail.adelphia.net ([68.168.78.211] helo=mta16.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2qdH-00039D-46 for ltru@ietf.org; Fri, 05 Jan 2007 10:05:26 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070105144901.MHBS2311.mta16.adelphia.net@DGBP7M81>; Fri, 5 Jan 2007 09:49:01 -0500 Message-ID: <004501c730da$ed05c2d0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00f901c72f6b$b56ca1b0$6501a8c0@DGBP7M81> <459C1197.80100@yahoo-inc.com> <00fd01c72f79$5b39a040$6501a8c0@DGBP7M81> <20070103223656.GB5718@ccil.org> <013701c72f9f$b3d980f0$6501a8c0@DGBP7M81> <6.0.0.20.2.20070105170143.02432570@localhost> Subject: Re: [Ltru] Unresolved issues for draft-4645bis Date: Fri, 5 Jan 2007 07:05:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > I think it would be good if your draft could be slightly more precise, > i.e. say > > "For fields of type 'language' or 'extlang', the first 'Description' > field appearing in the Registry corresponds to the Reference Name > assigned by ISO 639-3 if this entry exists in ISO 639-3." > > (or some such) This is wording for draft-4646bis (Addison and Mark's draft), not draft-4645bis (mine). But I agree with Martin's suggestion. >>(alias for Hiragana + Katakana) > > Why doesn't this read > Kana (alias for Hiragana + Katakana) ? Because it's taken directly from ISO 15924. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 05 11:33:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2s06-00071j-KT; Fri, 05 Jan 2007 11:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2s05-00071d-MH for ltru@ietf.org; Fri, 05 Jan 2007 11:33:01 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2s04-0002N2-FV for ltru@ietf.org; Fri, 05 Jan 2007 11:33:01 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H2s01-0006Uh-Pt; Fri, 05 Jan 2007 11:32:57 -0500 Date: Fri, 5 Jan 2007 11:32:57 -0500 To: Doug Ewell Subject: Re: [Ltru] Unresolved issues for draft-4645bis Message-ID: <20070105163257.GI19368@ccil.org> References: <00f901c72f6b$b56ca1b0$6501a8c0@DGBP7M81> <459C1197.80100@yahoo-inc.com> <00fd01c72f79$5b39a040$6501a8c0@DGBP7M81> <20070103223656.GB5718@ccil.org> <013701c72f9f$b3d980f0$6501a8c0@DGBP7M81> <6.0.0.20.2.20070105170143.02432570@localhost> <004501c730da$ed05c2d0$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004501c730da$ed05c2d0$6501a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > >Why doesn't this read > >Kana (alias for Hiragana + Katakana) ? > > Because it's taken directly from ISO 15924. I have just asked ISO 15924/RA to change this. -- All Gaul is divided into three parts: the part John Cowan that cooks with lard and goose fat, the part http://ccil.org/~cowan that cooks with olive oil, and the part that cowan@ccil.org cooks with butter. -- David Chessler _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 05 18:13:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yFC-00071o-WE; Fri, 05 Jan 2007 18:13:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yFC-00071j-HQ for ltru@ietf.org; Fri, 05 Jan 2007 18:13:02 -0500 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2yFB-0005Bj-8L for ltru@ietf.org; Fri, 05 Jan 2007 18:13:02 -0500 Received: from c83-248-96-54.bredband.comhem.se ([83.248.96.54]:61246 helo=chalmers95a69n) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1H2yF7-0000bq-9b; Sat, 06 Jan 2007 00:12:58 +0100 From: "Kent Karlsson" To: "'Martin Duerst'" , "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Unresolved issues for draft-4645bis Date: Sat, 6 Jan 2007 00:10:26 +0100 Message-ID: <008d01c7311e$b5d36b20$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <6.0.0.20.2.20070105170143.02432570@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1H2yF7-0000bq-9b. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1H2yF7-0000bq-9b 5486fbdc5fb7f5f0fef72f9bce001506 X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > >(alias for Hiragana + Katakana) > > Why doesn't this read > Kana (alias for Hiragana + Katakana) ? Which would not be much better. There is no defined notion of "+"-ing language names/codes, nor is there a defined notion of aliasing between language codes. (Which has bugged me from the first time I saw it..) "Kana (mix of Hiragana and Katakana)" would be suitably precise, and avoids the (here) troublesome notions of "+"-ing and aliasing. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 06 01:39:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H35Ct-0001oI-39; Sat, 06 Jan 2007 01:39:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H35Cq-0001o9-Op for ltru@ietf.org; Sat, 06 Jan 2007 01:39:04 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H35Cp-0005g6-G2 for ltru@ietf.org; Sat, 06 Jan 2007 01:39:04 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070106063858.VEEH5532.mta11.adelphia.net@DGBP7M81>; Sat, 6 Jan 2007 01:38:58 -0500 Message-ID: <003f01c7315d$587b1790$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <008d01c7311e$b5d36b20$6500a8c0@chalmers95a69n> Subject: Re: [Ltru] Unresolved issues for draft-4645bis Date: Fri, 5 Jan 2007 22:38:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: >> Why doesn't this read Kana (alias for Hiragana + Katakana) ? > > Which would not be much better. There is no defined notion of "+"-ing > language names/codes, nor is there a defined notion of aliasing > between language codes. (Which has bugged me from the first time I saw > it..) I think the concept of mixing two scripts into a single writing system, which is the standard M.O. for Japanese (and to a much lesser extent Korean), is more clearly defined than mixing two languages. Granted, es posible to have a mezcla of English y español in a single frase (and some people really do talk that way), but this is left to each application of language tags (such as Accept-Language) to handle in its own way. As for aliases, (1) this is not something that any of the ISO standards provide as a regular feature, only for the two Japanese script cases; and (2) the Registry does support a form of aliases through deprecated subtags. You can, for instance, use "ji" instead of "yi" for Yiddish, or "BU" instead of "MM" for Myanmar, though you are not encouraged to do so. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 06 07:41:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ArX-0006nI-80; Sat, 06 Jan 2007 07:41:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ArV-0006mI-Qu for ltru@ietf.org; Sat, 06 Jan 2007 07:41:25 -0500 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3AeC-00037p-85 for ltru@ietf.org; Sat, 06 Jan 2007 07:27:41 -0500 Received: from c83-248-96-54.bredband.comhem.se ([83.248.96.54]:63539 helo=chalmers95a69n) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1H3AeA-0004zB-7N; Sat, 06 Jan 2007 13:27:38 +0100 From: "Kent Karlsson" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Unresolved issues for draft-4645bis Date: Sat, 6 Jan 2007 13:25:09 +0100 Message-ID: <000b01c7318d$b5771ae0$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <003f01c7315d$587b1790$6501a8c0@DGBP7M81> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1H3AeA-0004zB-7N. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1H3AeA-0004zB-7N d3eb8491941ca559ed4acc638aa5e54d X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > Which would not be much better. There is no defined notion of "+"-ing > > language names/codes, nor is there a defined notion of aliasing > > between language codes. (Which has bugged me from the first I actually meant to write 'script' rather than 'language' here, of course. ... > I think the concept of mixing two scripts into a single writing system, > which is the standard M.O. for Japanese (and to a much lesser extent > Korean), is more clearly defined than mixing two languages. > As for aliases, (1) this is not something that any of the ISO standards > provide as a regular feature, only for the two Japanese script cases; Well, it does not define any kind of aliasing. I interpret 'alias' as something rather formal. 15924 *informally* uses the word 'alias' in one (now two) place(s). And what it "aliases" *to* is not something that can be formally expressed in ISO 15924 codes; there is no way of saying "Hira+Kata" (joining two or more codes to one, keeping the individual codes as subexpressions) as a formal code in ISO 15924. So I'd rather see that one does not use 'alias' for these, nor "+". > and (2) the Registry does support a form of aliases through deprecated > subtags. You can, for instance, use "ji" instead of "yi" for Yiddish, > or "BU" instead of "MM" for Myanmar, though you are not > encouraged to do so. Or rather, 'encouraged not to do so' ("deprecated"). So they aren't quite 'aliases' either, 'aliases' would be on a more equal footing. The Registry does not have a notion of '+'-ing script codes or similar, so aliasing still cannot be applied in the cases of Hrkt and Jpan. /kent k > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 06 12:07:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3F0t-0007rS-N2; Sat, 06 Jan 2007 12:07:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3F0s-0007rN-Ow for ltru@ietf.org; Sat, 06 Jan 2007 12:07:22 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3F0r-0007yN-Ft for ltru@ietf.org; Sat, 06 Jan 2007 12:07:22 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070106170716.JREE20139.mta9.adelphia.net@DGBP7M81>; Sat, 6 Jan 2007 12:07:16 -0500 Message-ID: <000f01c731b5$1e84cdd0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <000b01c7318d$b5771ae0$6500a8c0@chalmers95a69n> Subject: Re: [Ltru] Unresolved issues for draft-4645bis Date: Sat, 6 Jan 2007 09:07:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: > I actually meant to write 'script' rather than 'language' here, of > course. OK, that does make the rest of your post a bit more meaningful. You are talking about representing a mixture of Latin and Cyrillic scripts, not Swedish and Russian languages. >> As for aliases, (1) this is not something that any of the ISO >> standards provide as a regular feature, only for the two Japanese >> script cases; > > Well, it does not define any kind of aliasing. I interpret 'alias' as > something rather formal. 15924 *informally* uses the word 'alias' in > one (now two) place(s). And what it "aliases" *to* is not something > that can be formally expressed in ISO 15924 codes; there is no way of > saying "Hira+Kata" (joining two or more codes to one, keeping the > individual codes as subexpressions) as a formal code in ISO 15924. So > I'd rather see that one does not use 'alias' for these, nor "+". Let me see if I understand. When you talk about "aliases" as a feature you feel is important and missing in the ISO standards and in RFC 4646, are you talking about: (a) having one code element to represent a combination of others, as "Hrkt" represents the union of "Hira" and "Kana"? (b) having two code elements that represent the same (single) entity, sort of like "BU" and "MM" but without either one being deprecated? (c) both (a) and (b) above? (d) something else? > The Registry does not have a notion of '+'-ing script codes or > similar, so aliasing still cannot be applied in the cases of Hrkt and > Jpan. It's not the Registry, but rather the underlying RFC 4646, that disallows a construction like "jp-Hani+Hira+Kana". -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 06 12:22:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3FF3-0003zl-N1; Sat, 06 Jan 2007 12:22:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3FF2-0003zZ-AJ for ltru@ietf.org; Sat, 06 Jan 2007 12:22:00 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3FF0-0003FW-18 for ltru@ietf.org; Sat, 06 Jan 2007 12:22:00 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 4497426C210; Sat, 6 Jan 2007 18:21:46 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id A308F26C1E0; Sat, 6 Jan 2007 18:21:45 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 9614258EB6A; Sat, 6 Jan 2007 18:21:45 +0100 (CET) Date: Sat, 6 Jan 2007 18:21:45 +0100 From: Stephane Bortzmeyer To: Nicolas Krebs Message-ID: <20070106172145.GA23688@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ltru@ietf.org Subject: [Ltru] Re: two identical singleton extension tags issue X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Tue, Jan 02, 2007 at 11:22:17PM +0100, Nicolas Krebs wrote a message of 56 lines which said: > If a very simplified regexp is added, i would suggest to add the following > simplified ABNF as informative : > > Language-Tag = 1*8ALPHA *( "-" 1*8alphanum ) I agree. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 06 13:15:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3G4b-0005pe-9g; Sat, 06 Jan 2007 13:15:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3G4a-0005pZ-G9 for ltru@lists.ietf.org; Sat, 06 Jan 2007 13:15:16 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3G4Z-0001kJ-78 for ltru@lists.ietf.org; Sat, 06 Jan 2007 13:15:16 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H3G4Q-0001YV-R5 for ltru@lists.ietf.org; Sat, 06 Jan 2007 19:15:06 +0100 Received: from du-017a-032.access.de.clara.net ([213.221.75.32]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Jan 2007 19:15:06 +0100 Received: from nobody by du-017a-032.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Jan 2007 19:15:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 06 Jan 2007 19:14:19 +0100 Organization: Lines: 19 Message-ID: <459FE6FB.4BCB@xyzzy.claranet.de> References: <20061228103100.GA5181@generic-nic.net> <45940AF5.8010506@yahoo-inc.com> <45944F16.4C32@xyzzy.claranet.de> <45994327.30306@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017a-032.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: Security and nationality X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > One's language preference in a request header is hardly "private" > information. I think it's a "privacy" issue. If folks are aware of it they can solve it (e.g. modify their Accept list from time to time), if they are not aware of it it can be bad. All we can do is pointing it out as clearly as possible. > should we note that highly idiosyncratic Language Preference Lists > (to use the 4647 term) might act as a signature for the user? Yes. I'd prefer to use "privacy" as keyword instead of "signature", but maybe that's only a matter of taste. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 06 13:27:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3GG9-0001YV-9N; Sat, 06 Jan 2007 13:27:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3GG8-0001YQ-Ef for ltru@lists.ietf.org; Sat, 06 Jan 2007 13:27:12 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3GG7-0003kJ-5c for ltru@lists.ietf.org; Sat, 06 Jan 2007 13:27:12 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H3GG0-0002SN-Ju for ltru@lists.ietf.org; Sat, 06 Jan 2007 19:27:04 +0100 Received: from du-017a-032.access.de.clara.net ([213.221.75.32]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Jan 2007 19:27:04 +0100 Received: from nobody by du-017a-032.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 06 Jan 2007 19:27:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 06 Jan 2007 19:26:19 +0100 Organization: Lines: 22 Message-ID: <459FE9CB.6B7F@xyzzy.claranet.de> References: <20070106172145.GA23688@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017a-032.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Simplified ABNF (was: two identical singleton extension tags issue) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: >> If a very simplified regexp is added, i would suggest to add the >> following simplified ABNF as informative : >> Language-Tag = 1*8ALPHA *( "-" 1*8alphanum ) > I agree. To some degree we have that already in 4647 2.1. We also discussed the issue of the 2616 errata at this time. And decided that we don't dare "updates 2616". For unknown reasons that nit didn't make it yet into the 2616bis I-D, but apparently there might be a http BOF + WG later to fix this. In other words, it's not critical to have a "simplified ABNF" in 4646bis. IMHO it's even confusing, let 4647 and 2616bis handle this. After all it's already an approved 2616 erratum. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 06 15:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3HjC-00016x-Mb; Sat, 06 Jan 2007 15:01:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3HjA-00016n-Sd for ltru@ietf.org; Sat, 06 Jan 2007 15:01:16 -0500 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3Hj9-0000Bo-2w for ltru@ietf.org; Sat, 06 Jan 2007 15:01:16 -0500 Received: from c83-248-96-54.bredband.comhem.se ([83.248.96.54]:62781 helo=chalmers95a69n) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1H3Hj3-0008GJ-3c; Sat, 06 Jan 2007 21:01:09 +0100 From: "Kent Karlsson" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Unresolved issues for draft-4645bis Date: Sat, 6 Jan 2007 20:58:27 +0100 Message-ID: <001201c731cd$0ffffd80$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <000f01c731b5$1e84cdd0$6501a8c0@DGBP7M81> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1H3Hj3-0008GJ-3c. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1H3Hj3-0008GJ-3c 72dbbb5be962447af3b95ee1190f0d35 X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote > Let me see if I understand. When you talk about "aliases" as a = feature=20 > you feel is important and missing in the ISO standards and in=20 I did not say that. I just said that it is not there, and hence cannot = be referred to. Just a statement of that fact, not saying that the concept is missing (as different from just not being there). (The 'property = value aliases' in 15924 are, while true aliases, out of scope for the LST registry, since they do not fullfill the syntactic (4-letter) = requirement.) I.e. I'm NOT suggesting an introduction of an alias concept for 4-letter script codes. > (d) something else? Only that=20 Hrkt 412 (alias for Hiragana + Katakana) (alias pour hiragana + = katakana)=20 and=20 Jpan 413 Japanese (alias for Han + Hiragana + Katakana) japonais (alias pour han + hiragana + katakana)=20 should be changed so as to NOT refer to "alias" nor to "+". I would suggest to use Hrkt 412 Kana (mix of Hiragana and Katakana) (me=CC=81lange de = hiragana et katakana)=20 and=20 Jpan 413 Japanese (alias for Han, Hiragana, and Katakana) japonais (me=CC=81lange de han, hiragana et katakana)=20 respectively (for 15924 and by implication the similar text for LST). > > The Registry does not have a notion of '+'-ing script codes or=20 > > similar, so aliasing still cannot be applied in the cases of Hrkt = and=20 > > Jpan. >=20 > It's not the Registry, but rather the underlying RFC 4646, that=20 > disallows a construction like "jp-Hani+Hira+Kana". Indeed. Though such a thing may be useful, I'm ***not at all*** pushing = for introducing it. Just that one should not refer to a construct that is = not there. (Again NOT saying that it is 'missing', as opposed to 'not there'.) /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 06 15:52:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3IWW-00020K-Og; Sat, 06 Jan 2007 15:52:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3IWU-00020A-Fn for ltru@ietf.org; Sat, 06 Jan 2007 15:52:14 -0500 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3IWS-0001e9-6p for ltru@ietf.org; Sat, 06 Jan 2007 15:52:14 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id E05B1240813; Sat, 6 Jan 2007 21:52:08 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 66554111E9; Sat, 6 Jan 2007 21:49:34 +0100 (CET) Date: Sat, 6 Jan 2007 21:49:34 +0100 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20070106204934.GA10904@sources.org> References: <459AF83C.1030800@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <459AF83C.1030800@yahoo-inc.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org Subject: [Ltru] Re: Security and nationality X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Tue, Jan 02, 2007 at 04:26:36PM -0800, Addison Phillips wrote a message of 54 lines which said: > It might not have occurred to you, but mailers might use this > information to send bounce, error, and other messages in the > language that the user prefers. Sure, there are a lot of interesting use to such an header (although I wonder how many MTA read the non-standard X-Accept-Language header before generating the bounce...). But the point of Jukka K. Korpela's story was, I believe, that the ordinary user who configures his software to be in Swahili might not understand that, from now on, his software will tell everyone about his preferences... The proposal "It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic preferences of the user in every request." seems reasonable to me. The default behavior of Thunderbird is a concern to me, too. IMHO, we should warn implementors about privacy issues. (I do not suggest to make specific requirments such as "MUST NOT send the language preference by default" but I suggest to warn "There may be a problem here".) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 06 20:38:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Myv-0003vU-ST; Sat, 06 Jan 2007 20:37:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Myv-0003uW-53 for ltru@ietf.org; Sat, 06 Jan 2007 20:37:53 -0500 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3Myt-0001BJ-RK for ltru@ietf.org; Sat, 06 Jan 2007 20:37:53 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070107012616.CBJF25578.mta15.adelphia.net@DGBP7M81>; Sat, 6 Jan 2007 20:26:16 -0500 Message-ID: <002f01c731fc$724cbda0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <001201c731cd$0ffffd80$6500a8c0@chalmers95a69n> Subject: Re: [Ltru] Unresolved issues for draft-4645bis Date: Sat, 6 Jan 2007 17:37:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: > I did not say that. I just said that it is not there, and hence cannot > be referred to. Just a statement of that fact, not saying that the > concept is missing (as different from just not being there). (The > 'property value aliases' in 15924 are, while true aliases, out of > scope for the LST registry, since they do not fullfill the syntactic > (4-letter) requirement.) I.e. I'm NOT suggesting an introduction of an > alias concept for 4-letter script codes. I understand now. This is a question of changing the descriptions in ISO 15924 so they do not use the word "alias" or the symbol "+" (though I don't see why the plus sign is a problem). My apologies for the misunderstanding. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 07 11:48:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3bBi-0007AX-3H; Sun, 07 Jan 2007 11:48:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3bBg-00076e-Rq for ltru@ietf.org; Sun, 07 Jan 2007 11:48:00 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3bBf-000747-HT for ltru@ietf.org; Sun, 07 Jan 2007 11:48:00 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=EqnjhNxL3AKGb0Jq/VuxWqpomYCxjcUwKGLdVGE+HH2enx3CG5f/S8JQBXT7rYzw; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.3.235] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1H3bBb-0000e1-NY for ltru@ietf.org; Sun, 07 Jan 2007 11:47:55 -0500 Message-ID: <001e01c7327b$fc451320$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <459AF83C.1030800@yahoo-inc.com> <20070106204934.GA10904@sources.org> Subject: Re: [Ltru] Re: Security and nationality Date: Sun, 7 Jan 2007 08:50:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee61d9b5d6e9e5ef7dd83469a5fac628c6d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.3.235 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Stephane Bortzmeyer" > To: "Addison Phillips" > Cc: > Sent: Saturday, January 06, 2007 12:49 PM > Subject: [Ltru] Re: Security and nationality .... > The proposal "It might be contrary to the privacy expectations of the > user to send an Accept-Language header with the complete linguistic > preferences of the user in every request." seems reasonable to me. The > default behavior of Thunderbird is a concern to me, too. IMHO, we > should warn implementors about privacy issues. > > (I do not suggest to make specific requirments such as "MUST NOT send > the language preference by default" but I suggest to warn "There may > be a problem here".) ... This thread seems to center on potential problems in other specifications, rather than intrinsic problems of language tags. Instead of talking about specific headers in other protocols, I think we should stay generic. If folks believe it is necessary to change the current text (I don't), how about something like: Language tags used in, for example, content negotiation, like any other information exchanged on the Internet, might be a source of concern because they might be used to make inferences about sender. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 07 18:25:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3hOc-0004mr-4l; Sun, 07 Jan 2007 18:25:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3hOa-0004mm-0w for ltru@ietf.org; Sun, 07 Jan 2007 18:25:45 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3hOY-0001wi-OA for ltru@ietf.org; Sun, 07 Jan 2007 18:25:44 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 853142580CB for ; Mon, 8 Jan 2007 00:21:58 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12706-10 for ; Mon, 8 Jan 2007 00:21:51 +0100 (CET) Received: from [192.168.1.108] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id C85892580C6 for ; Mon, 8 Jan 2007 00:21:51 +0100 (CET) Date: Mon, 08 Jan 2007 00:25:31 +0100 From: Harald Alvestrand To: ltru@ietf.org Message-ID: X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ltru] Status of ISO 639-6? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org My attention was drawn to someone removing the note on Wikipedia saying "ISO 639-3 could be approved before the end of 2006", with the comment "it obviously didn't happen". Does anyone know the status of 639-3, what changes have been made, and plans/timelines for finishing it? Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 07 19:53:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ikx-0005Ya-C1; Sun, 07 Jan 2007 19:52:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ikw-0005YP-18 for ltru@ietf.org; Sun, 07 Jan 2007 19:52:54 -0500 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H3iks-0000U2-Ij for ltru@ietf.org; Sun, 07 Jan 2007 19:52:53 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070108005247.GTTT2904.mta13.adelphia.net@DGBP7M81> for ; Sun, 7 Jan 2007 19:52:47 -0500 Message-ID: <003801c732bf$5132e220$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 7 Jan 2007 16:52:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ltru] Re: Security and nationality X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > This thread seems to center on potential problems in other > specifications, rather than intrinsic problems of language tags. > Instead of talking about specific headers in other protocols, I think > we should stay generic. I tend to agree. We may choose to mention specific insecure purposes to which other applications put language tags, but we do not need to go into great depth about them or act as though the problem is with the tags. Some mail agents send the user's internal machine ID string as part of a Message-ID, and some e-mail viruses send themselves to every contact within the victim's address book, but that does not mean machine IDs and address books are inherently insecure. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 07 21:00:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3jo7-0007ib-M2; Sun, 07 Jan 2007 21:00:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3jo5-0007hM-M5 for ltru@ietf.org; Sun, 07 Jan 2007 21:00:13 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3jo1-0008F2-R5 for ltru@ietf.org; Sun, 07 Jan 2007 21:00:13 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l08201Tt005619 for ; Mon, 8 Jan 2007 11:00:01 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4516_f36dbdae_9ebb_11db_927d_0014221fa3c9; Mon, 08 Jan 2007 11:00:01 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:33674) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 8 Jan 2007 10:59:16 +0900 Message-Id: <6.0.0.20.2.20070108104252.1885a850@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 08 Jan 2007 10:43:26 +0900 To: Stephane Bortzmeyer , Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Re: Security and nationality In-Reply-To: <20070106204934.GA10904@sources.org> References: <459AF83C.1030800@yahoo-inc.com> <20070106204934.GA10904@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 05:49 07/01/07, Stephane Bortzmeyer wrote: >(I do not suggest to make specific requirments such as "MUST NOT send >the language preference by default" but I suggest to warn "There may >be a problem here".) This is what a security section is about anyway. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 07 21:00:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3jo5-0007gi-IB; Sun, 07 Jan 2007 21:00:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3jo4-0007e2-Pt for ltru@lists.ietf.org; Sun, 07 Jan 2007 21:00:12 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3jo1-0008FC-R4 for ltru@lists.ietf.org; Sun, 07 Jan 2007 21:00:12 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l08203x0005626 for ; Mon, 8 Jan 2007 11:00:05 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4496_f4382198_9ebb_11db_9a36_0014221fa3c9; Mon, 08 Jan 2007 11:00:02 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:33674) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 8 Jan 20From ltru-bounces@ietf.org Sun Jan 07 21:00:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3jo7-0007ib-M2; Sun, 07 Jan 2007 21:00:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3jo5-0007hM-M5 for ltru@ietf.org; Sun, 07 Jan 2007 21:00:13 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3jo1-0008F2-R5 for ltru@ietf.org; Sun, 07 Jan 2007 21:00:13 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l08201Tt005619 for ; Mon, 8 Jan 2007 11:00:01 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4516_f36dbdae_9ebb_11db_927d_0014221fa3c9; Mon, 08 Jan 2007 11:00:01 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:33674) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 8 Jan 2007 10:59:16 +0900 Message-Id: <6.0.0.20.2.20070108104252.1885a850@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 08 Jan 2007 10:43:26 +0900 To: Stephane Bortzmeyer , Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Re: Security and nationality In-Reply-To: <20070106204934.GA10904@sources.org> References: <459AF83C.1030800@yahoo-inc.com> <20070106204934.GA10904@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 05:49 07/01/07, Stephane Bortzmeyer wrote: >(I do not suggest to make specific requirments such as "MUST NOT send >the language preference by default" but I suggest to warn "There may >be a problem here".) This is what a security section is about anyway. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 07 21:00:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3jo5-0007gi-IB; Sun, 07 Jan 2007 21:00:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3jo4-0007e2-Pt for ltru@lists.ietf.org; Sun, 07 Jan 2007 21:00:12 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3jo1-0008FC-R4 for ltru@lists.ietf.org; Sun, 07 Jan 2007 21:00:12 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l08203x0005626 for ; Mon, 8 Jan 2007 11:00:05 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4496_f4382198_9ebb_11db_9a36_0014221fa3c9; Mon, 08 Jan 2007 11:00:02 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:33674) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 8 Jan 2007 10:59:17 +0900 Message-Id: <6.0.0.20.2.20070108104340.1885ba90@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 08 Jan 2007 10:48:01 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Security and nationality In-Reply-To: <459FE6FB.4BCB@xyzzy.claranet.de> References: <20061228103100.GA5181@generic-nic.net> <45940AF5.8010506@yahoo-inc.com> <45944F16.4C32@xyzzy.claranet.de> <45994327.30306@yahoo-inc.com> <459FE6FB.4BCB@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 03:14 07/01/07, Frank Ellermann wrote: >Addison Phillips wrote: > >> One's language preference in a request header is hardly "private" >> information. Privacy is a highly personal issue. Some people keep some aspects of their identity highly secret, whereas others freely tell everybody about the same aspects of their identity. Examples are easy to find, including for language preferences. >I think it's a "privacy" issue. If folks are aware of it they can >solve it (e.g. modify their Accept list from time to time), if they >are not aware of it it can be bad. All we can do is pointing it >out as clearly as possible. > >> should we note that highly idiosyncratic Language Preference Lists >> (to use the 4647 term) might act as a signature for the user? > >Yes. I'd prefer to use "privacy" as keyword instead of "signature", >but maybe that's only a matter of taste. I agree it is about "privacy". "privacy" is about data about yourself that may be revealed, when and where you don't expect it. It raises the right flags in readers, such as the fact that in the extreme, this can lead to personal identification, or (I seriously doubt this can happen for language preferences only) identity theft. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru 07 10:59:17 +0900 Message-Id: <6.0.0.20.2.20070108104340.1885ba90@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 08 Jan 2007 10:48:01 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Security and nationality In-Reply-To: <459FE6FB.4BCB@xyzzy.claranet.de> References: <20061228103100.GA5181@generic-nic.net> <45940AF5.8010506@yahoo-inc.com> <45944F16.4C32@xyzzy.claranet.de> <45994327.30306@yahoo-inc.com> <459FE6FB.4BCB@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 03:14 07/01/07, Frank Ellermann wrote: >Addison Phillips wrote: > >> One's language preference in a request header is hardly "private" >> information. Privacy is a highly personal issue. Some people keep some aspects of their identity highly secret, whereas others freely tell everybody about the same aspects of their identity. Examples are easy to find, including for language preferences. >I think it's a "privacy" issue. If folks are aware of it they can >solve it (e.g. modify their Accept list from time to time), if they >are not aware of it it can be bad. All we can do is pointing it >out as clearly as possible. > >> should we note that highly idiosyncratic Language Preference Lists >> (to use the 4647 term) might act as a signature for the user? > >Yes. I'd prefer to use "privacy" as keyword instead of "signature", >but maybe that's only a matter of taste. I agree it is about "privacy". "privacy" is about data about yourself that may be revealed, when and where you don't expect it. It raises the right flags in readers, such as the fact that in the extreme, this can lead to personal identification, or (I seriously doubt this can happen for language preferences only) identity theft. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 07 22:51:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3lXI-0002Jl-JT; Sun, 07 Jan 2007 22:51:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3lXH-0002GP-DQ for ltru@ietf.org; Sun, 07 Jan 2007 22:50:59 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3lXF-0005Xy-2g for ltru@ietf.org; Sun, 07 Jan 2007 22:50:59 -0500 Received: from [10.72.66.90] (snvvpn-10-72-66-c90.corp.yahoo.com [10.72.66.90]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l083oh0K009009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jan 2007 19:50:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=GErJXvC3XDNAmH1pIndN0lLkgfNA71EAQHoomdbbA5K1eO9g8mCOY61EkWOqyv5O Message-ID: <45A1BF93.9040703@yahoo-inc.com> Date: Sun, 07 Jan 2007 19:50:43 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Re: Security and nationality References: <459AF83C.1030800@yahoo-inc.com> <20070106204934.GA10904@sources.org> <001e01c7327b$fc451320$6601a8c0@oemcomputer> In-Reply-To: <001e01c7327b$fc451320$6601a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy noted: > > This thread seems to center on potential problems in other specifications, > rather than intrinsic problems of language tags. Instead of talking about > specific headers in other protocols, I think we should stay generic. > If folks believe it is necessary to change the current text (I don't), +1 to the "I don't" > how > about something like: > > Language tags used in, for example, content negotiation, like any > other information exchanged on the Internet, might be a source > of concern because they might be used to make inferences > about sender. > I can agree with this. In fact, I think it might be better to eliminate the example (it would make the text stronger): Language tags, like any other information exchanged on the Internet, might be a source of concern because the might be used to make inferences about the user. We might also wish to repeat the warning from 4647 (only s/range/tag/): -- In addition, unique or highly unusual language ranges or combinations of language ranges might be used to track a specific individual's activities. -- Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 07 22:54:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3laN-0003KK-QC; Sun, 07 Jan 2007 22:54:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3laN-0003KF-9h for ltru@lists.ietf.org; Sun, 07 Jan 2007 22:54:11 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3laK-0005wI-Ry for ltru@lists.ietf.org; Sun, 07 Jan 2007 22:54:11 -0500 Received: from [10.72.66.90] (snvvpn-10-72-66-c90.corp.yahoo.com [10.72.66.90]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l083rrbU009131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jan 2007 19:53:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=q9S9K81Yhj8ra03UARTvPyCLCudH5By4wO29OYPJPXGeDUDVeGyWt36FYw0H4+vX Message-ID: <45A1C051.9000709@yahoo-inc.com> Date: Sun, 07 Jan 2007 19:53:53 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Re: Security and nationality References: <20061228103100.GA5181@generic-nic.net> <45940AF5.8010506@yahoo-inc.com> <45944F16.4C32@xyzzy.claranet.de> <45994327.30306@yahoo-inc.com> <459FE6FB.4BCB@xyzzy.claranet.de> <6.0.0.20.2.20070108104340.1885ba90@localhost> In-Reply-To: <6.0.0.20.2.20070108104340.1885ba90@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I wrote the following *before* responding to Randy's note, but sent it after I read Randy's. I forward this just because I think it presents things clearly. ~Addison ============ I think you guys are parsing my words too closely, since I didn't suggest using the word signature. I agree that the issue is "privacy". I used the word "signature" in reference to the fact that an unusual combination of language ranges might be very rare---even unique. For example, at least one of my browsers emits an Accept-Language header that is probably unique. I think there are two cases for language tags to present security or privacy risks. We probably should deal with both: 1. The privacy issue could affect language tags when they are applied to documents, since they might identify texts (and thus authors) that are "offensive" or which are being suppressed or tracked... or even provide a filter leading to such discrimination. I note that almost the first step in providing for Internet search is language identification. 2. The privacy issue we document, though, really has to do with language *ranges* and their combinations and thus should belong in 4647. Unlike with documents that you author (which you can protect in various ways), ranges are usually emitted when requesting content, which, in turn, may reside on remote systems. Actually, we do mention it in 4647: In addition, unique or highly unusual language ranges or combinations of language ranges might be used to track a specific individual's activities. I think these are separate and can be identified separately. Aside from that, I think that making the text far more scary is counter-productive. Martin Duerst wrote: > At 03:14 07/01/07, Frank Ellermann wrote: >> Addison Phillips wrote: >> >>> One's language preference in a request header is hardly "private" >>> information. > > Privacy is a highly personal issue. Some people keep some aspects > of their identity highly secret, whereas others freely tell everybody > about the same aspects of their identity. Examples are easy to find, > including for language preferences. > >> I think it's a "privacy" issue. If folks are aware of it they can >> solve it (e.g. modify their Accept list from time to time), if they >> are not aware of it it can be bad. All we can do is pointing it >> out as clearly as possible. >> >>> should we note that highly idiosyncratic Language Preference Lists >>> (to use the 4647 term) might act as a signature for the user? >> Yes. I'd prefer to use "privacy" as keyword instead of "signature", >> but maybe that's only a matter of taste. > > I agree it is about "privacy". "privacy" is about data about yourself > that may be revealed, when and where you don't expect it. It raises > the right flags in readers, such as the fact that in the extreme, this > can lead to personal identification, or (I seriously doubt this can > happen for language preferences only) identity theft. > > Regards, Martin. > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 07 23:55:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3mXF-0002Em-3v; Sun, 07 Jan 2007 23:55:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3mXD-0002ED-Ne for ltru@ietf.org; Sun, 07 Jan 2007 23:54:59 -0500 Received: from smtp4.pp.htv.fi ([213.243.153.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3mXB-0006DE-BX for ltru@ietf.org; Sun, 07 Jan 2007 23:54:59 -0500 Received: from Raahattava (cs181252091.pp.htv.fi [82.181.252.91]) by smtp4.pp.htv.fi (Postfix) with ESMTP id 58AA65BC079; Mon, 8 Jan 2007 06:54:53 +0200 (EET) From: "Erkki I. Kolehmainen" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: VS: [Ltru] Re: Security and nationality Date: Mon, 8 Jan 2007 06:54:52 +0200 Message-ID: <002701c732e1$22642f90$0d00a8c0@Raahattava> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <003801c732bf$5132e220$6501a8c0@DGBP7M81> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Erkki I. Kolehmainen Tilkankatu 12 A 3, FI-00300 Helsinki, Finland Puh. (09) 4368 2643, 0400 825 943; Tel. +358 9 4368 2643, +358 400 825 = 943 =20 -----Alkuper=C3=A4inen viesti----- L=C3=A4hett=C3=A4j=C3=A4: Doug Ewell [mailto:dewell@adelphia.net]=20 L=C3=A4hetetty: 8. tammikuuta 2007 2:53 Vastaanottaja: LTRU Working Group Aihe: [Ltru] Re: Security and nationality Randy Presuhn wrote: > This thread seems to center on potential problems in other > specifications, rather than intrinsic problems of language tags.=20 > Instead of talking about specific headers in other protocols, I think=20 > we should stay generic. I tend to agree. We may choose to mention specific insecure purposes to = which other applications put language tags, but we do not need to go=20 into great depth about them or act as though the problem is with the=20 tags. Some mail agents send the user's internal machine ID string as part of a = Message-ID, and some e-mail viruses send themselves to every contact=20 within the victim's address book, but that does not mean machine IDs and = address books are inherently insecure. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 = http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 08 00:00:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3mc3-00048g-Ey; Sun, 07 Jan 2007 23:59:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3mc1-00047g-SY for ltru@lists.ietf.org; Sun, 07 Jan 2007 23:59:57 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3mbz-0006pd-GB for ltru@lists.ietf.org; Sun, 07 Jan 2007 23:59:57 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H3mbs-0006LP-VC for ltru@lists.ietf.org; Mon, 08 Jan 2007 05:59:48 +0100 Received: from d255027.dialin.hansenet.de ([80.171.255.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Jan 2007 05:59:48 +0100 Received: from nobody by d255027.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Jan 2007 05:59:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 08 Jan 2007 05:58:45 +0100 Organization: Lines: 17 Message-ID: <45A1CF85.2472@xyzzy.claranet.de> References: <459AF83C.1030800@yahoo-inc.com> <20070106204934.GA10904@sources.org> <001e01c7327b$fc451320$6601a8c0@oemcomputer> <45A1BF93.9040703@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d255027.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: Security and nationality X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Language tags, like any other information exchanged on the Internet, > might be a source of concern because the might be used to make > inferences about the user. The "any" doesn't help, you can reduce that further to: Language tags might be a source of privacy concerns because they might be used to make inferences about the user. > We might also wish to repeat the warning from 4647 (only s/range/tag/) +1 Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 08 00:21:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3mwy-0004Zs-GI; Mon, 08 Jan 2007 00:21:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3mwx-0004Zn-N9 for ltru@lists.ietf.org; Mon, 08 Jan 2007 00:21:35 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3mww-0001Ty-EQ for ltru@lists.ietf.org; Mon, 08 Jan 2007 00:21:35 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H3mwm-0008DQ-5a for ltru@lists.ietf.org; Mon, 08 Jan 2007 06:21:24 +0100 Received: from d255027.dialin.hansenet.de ([80.171.255.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Jan 2007 06:21:24 +0100 Received: from nobody by d255027.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Jan 2007 06:21:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 08 Jan 2007 06:20:35 +0100 Organization: Lines: 7 Message-ID: <45A1D4A3.1C6C@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: d255027.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Ltru] Re: Status of ISO 639-3? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Harald Alvestrand wrote: > Does anyone know the status of 639-3 Somebody mentioned this year that they're at 60:0 (?), whatever that is, it sounds like "after last call". _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 08 00:27:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3n2Z-0006MG-2q; Mon, 08 Jan 2007 00:27:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3n2Y-0006MB-3w for ltru@lists.ietf.org; Mon, 08 Jan 2007 00:27:22 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3n2T-0002VP-SC for ltru@lists.ietf.org; Mon, 08 Jan 2007 00:27:22 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H3n2T-0008HS-6W; Mon, 08 Jan 2007 00:27:17 -0500 Date: Mon, 8 Jan 2007 00:27:17 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: Status of ISO 639-3? Message-ID: <20070108052717.GD2908@ccil.org> References: <45A1D4A3.1C6C@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45A1D4A3.1C6C@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Somebody mentioned this year that they're at 60:0 (?), > whatever that is, it sounds like "after last call". http://www.iso.org/iso/en/widepages/stagetable.html explains the stages of ISO standards. 60.00 means that publication is in progress; it's equivalent to being in the RFC Editor queue. The next stage is 60.60, which means it's actually published as an International Standard, can be ordered in hard copy (but without the tables) from national bodies, etc. -- John Cowan http://ccil.org/~cowan cowan@ccil.org In might the Feanorians / that swore the unforgotten oath brought war into Arvernien / with burning and with broken troth. and Elwing from her fastness dim / then cast her in the waters wide, but like a mew was swiftly borne, / uplifted o'er the roaring tide. --the Earendillinwe _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 08 05:14:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3rWk-0000cJ-1w; Mon, 08 Jan 2007 05:14:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3rWi-0000cB-Gs for ltru@lists.ietf.org; Mon, 08 Jan 2007 05:14:48 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3rWg-0000bI-Vb for ltru@lists.ietf.org; Mon, 08 Jan 2007 05:14:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 4B59626C1E4; Mon, 8 Jan 2007 11:14:42 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id B03FF26C15B; Mon, 8 Jan 2007 11:14:41 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id A492C58EBC3; Mon, 8 Jan 2007 11:14:41 +0100 (CET) Date: Mon, 8 Jan 2007 11:14:41 +0100 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20070108101441.GA12369@nic.fr> References: <20070106204934.GA10904@sources.org> <001e01c7327b$fc451320$6601a8c0@oemcomputer> <45A1BF93.9040703@yahoo-inc.com> <45A1CF85.2472@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45A1CF85.2472@xyzzy.claranet.de> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Security and nationality X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Jan 08, 2007 at 05:58:45AM +0100, Frank Ellermann wrote a message of 17 lines which said: > > Language tags, like any other information exchanged on the Internet, > > might be a source of concern because the might be used to make > > inferences about the user. > > The "any" doesn't help, you can reduce that further to: -1 The text is so general and vague ("life can be risky") that it will probably be ignored. We really need to be more specific. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 08 05:27:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3rj2-0005xu-K5; Mon, 08 Jan 2007 05:27:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3rj1-0005xk-Tq for ltru@lists.ietf.org; Mon, 08 Jan 2007 05:27:31 -0500 Received: from mail03.svc.cra.dublin.eircom.net ([159.134.118.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3riu-0003sy-S3 for ltru@lists.ietf.org; Mon, 08 Jan 2007 05:27:31 -0500 Received: (qmail 76750 messnum 287048 invoked from network[194.125.174.65/ts09-065.dublin.indigo.ie]); 8 Jan 2007 10:27:23 -0000 Received: from ts09-065.dublin.indigo.ie (HELO ?194.125.174.65?) (194.125.174.65) by mail03.svc.cra.dublin.eircom.net (qp 76750) with SMTP; 8 Jan 2007 10:27:23 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <20070108101441.GA12369@nic.fr> References: <20070106204934.GA10904@sources.org> <001e01c7327b$fc451320$6601a8c0@oemcomputer> <45A1BF93.9040703@yahoo-inc.com> <45A1CF85.2472@xyzzy.claranet.de> <20070108101441.GA12369@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: Security and nationality Date: Mon, 8 Jan 2007 10:30:09 +0000 To: ltru@lists.ietf.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I suggest "can" and "could" rather than "might" x 2 below - that is, =20 if the majority feel such a vague statement is worth including at all =20= (which I doubt, because all it does is point to an obvious misuse =20 while adding nothing of substance). mg On 8 Jan 2007, at 10:14, scr=EDobh Stephane Bortzmeyer: > On Mon, Jan 08, 2007 at 05:58:45AM +0100, > Frank Ellermann wrote > a message of 17 lines which said: > > >>> Language tags, like any other information exchanged on the =20 >>> Internet, >>> might be a source of concern because the might be used to make >>> inferences about the user. >>> >> >> The "any" doesn't help, you can reduce that further to: >> > > -1 > > The text is so general and vague ("life can be risky") that it will > probably be ignored. We really need to be more specific. - - 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@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 08 13:00:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ymx-0003Vp-79; Mon, 08 Jan 2007 13:00:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ymu-0003Uz-LU for ltru@lists.ietf.org; Mon, 08 Jan 2007 13:00:01 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3ymp-000112-Bc for ltru@lists.ietf.org; Mon, 08 Jan 2007 13:00:00 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H3ymo-0001Iu-3O for ltru@lists.ietf.org; Mon, 08 Jan 2007 18:59:54 +0100 Received: from 212.82.251.141 ([212.82.251.141]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Jan 2007 18:59:54 +0100 Received: from nobody by 212.82.251.141 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Jan 2007 18:59:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 08 Jan 2007 18:59:15 +0100 Organization: Lines: 11 Message-ID: <45A28673.16F2@xyzzy.claranet.de> References: <45A1D4A3.1C6C@xyzzy.claranet.de> <20070108052717.GD2908@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.141 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Ltru] Re: Status of ISO 639-3? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > http://www.iso.org/iso/en/widepages/stagetable.html explains > the stages of ISO standards. 60.00 means that publication > is in progress; it's equivalent to being in the RFC Editor queue. Okay, if you take that into account it sounds more like AUTH48, with the bonus that there's no question about the number... :-) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 08 13:06:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ysj-0006er-QJ; Mon, 08 Jan 2007 13:06:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ysi-0006ee-CW for ltru@lists.ietf.org; Mon, 08 Jan 2007 13:06:00 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H3ysg-0008VB-0Z for ltru@lists.ietf.org; Mon, 08 Jan 2007 13:06:00 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H3ysF-0002Rr-7q for ltru@lists.ietf.org; Mon, 08 Jan 2007 19:05:31 +0100 Received: from 212.82.251.141 ([212.82.251.141]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Jan 2007 19:05:31 +0100 Received: from nobody by 212.82.251.141 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Jan 2007 19:05:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 08 Jan 2007 19:04:59 +0100 Organization: Lines: 12 Message-ID: <45A287CB.6618@xyzzy.claranet.de> References: <20070106204934.GA10904@sources.org> <001e01c7327b$fc451320$6601a8c0@oemcomputer> <45A1BF93.9040703@yahoo-inc.com> <45A1CF85.2472@xyzzy.claranet.de> <20070108101441.GA12369@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.141 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Security and nationality X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Marion Gunn wrote: > I suggest "can" and "could" rather than "might" x 2 below - that is, > if the majority feel such a vague statement is worth including at all > (which I doubt, because all it does is point to an obvious misuse > while adding nothing of substance). If searches for "privacy" find something in this direction I'm happy with it. We don't need specific recipes how to abuse language tags. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 09 15:36:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Nhq-0001nG-MB; Tue, 09 Jan 2007 15:36:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Nho-0001mg-HC for ltru@lists.ietf.org; Tue, 09 Jan 2007 15:36:24 -0500 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound4-sin-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Nhl-0000l8-7D for ltru@lists.ietf.org; Tue, 09 Jan 2007 15:36:24 -0500 Received: from outbound4-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound4-sin-R.bigfish.com (Postfix) with ESMTP id 14F8A9009B1; Tue, 9 Jan 2007 20:36:15 +0000 (UTC) Received: from mail42-sin-R.bigfish.com (unknown [10.3.252.3]) by outbound4-sin.bigfish.com (Postfix) with ESMTP id F34ED280067; Tue, 9 Jan 2007 20:36:14 +0000 (UTC) Received: from mail42-sin (localhost.localdomain [127.0.0.1]) by mail42-sin-R.bigfish.com (Postfix) with ESMTP id C83F996015D; Tue, 9 Jan 2007 20:36:14 +0000 (UTC) X-BigFish: VP Received: by mail42-sin (MessageSwitch) id 1168374974768869_8626; Tue, 9 Jan 2007 20:36:14 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail42-sin.bigfish.com (Postfix) with ESMTP id 4563A760071; Tue, 9 Jan 2007 20:36:14 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007010912304436-2248185 ; Tue, 9 Jan 2007 12:30:44 -0800 In-Reply-To: <45A287CB.6618@xyzzy.claranet.de> To: Frank Ellermann Subject: Re: [Ltru] Re: Security and nationality MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Tue, 9 Jan 2007 12:25:15 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 01/09/2007 12:25:15, Serialize complete at 01/09/2007 12:25:15, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/09/2007 12:30:44 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/09/2007 12:40:13 PM, Serialize complete at 01/09/2007 12:40:13 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0048817446==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0048817446== Content-Type: multipart/alternative; boundary="=_alternative 00704F7A8825725E_=" This is a multipart message in MIME format. --=_alternative 00704F7A8825725E_= Content-Type: text/plain; charset="US-ASCII" +1 Karen Broome Frank Ellermann 01/08/2007 10:04 AM To ltru@lists.ietf.org cc Subject [Ltru] Re: Security and nationality Marion Gunn wrote: > I suggest "can" and "could" rather than "might" x 2 below - that is, > if the majority feel such a vague statement is worth including at all > (which I doubt, because all it does is point to an obvious misuse > while adding nothing of substance). If searches for "privacy" find something in this direction I'm happy with it. We don't need specific recipes how to abuse language tags. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 00704F7A8825725E_= Content-Type: text/html; charset="US-ASCII"
+1

Karen Broome


Frank Ellermann <nobody@xyzzy.claranet.de>

01/08/2007 10:04 AM

To
ltru@lists.ietf.org
cc
Subject
[Ltru] Re: Security and nationality





Marion Gunn wrote:

> I suggest "can" and "could" rather than "might" x 2 below - that is,
> if the majority feel such a vague statement is worth including at all
> (which I doubt, because all it does is point to an obvious misuse
> while adding nothing of substance).

If searches for "privacy" find something in this direction I'm happy
with it.  We don't need specific recipes how to abuse language tags.

Frank



_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 00704F7A8825725E_=-- --===============0048817446== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0048817446==-- From ltru-bounces@ietf.org Tue Jan 09 15:44:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Npi-0005wO-Au; Tue, 09 Jan 2007 15:44:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Npg-0005un-RJ for ltru@ietf.org; Tue, 09 Jan 2007 15:44:32 -0500 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4NlV-0002bT-Im for ltru@ietf.org; Tue, 09 Jan 2007 15:40:14 -0500 Received: by an-out-0708.google.com with SMTP id d30so2824165and for ; Tue, 09 Jan 2007 12:40:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=r9Mb8hoifVke6eqxIqrtTF6pqQmFVfYkaYo9KtwD67s/INB9V4L60W4X27GOjth2FVxYs9IUMZkM8ZXW9MypJ778ZSlxeL1vFc6KkzboaItVIkCLwHe8UCUaJlqnJgMqiT1Y45X4OTemPZBJ5x5wfPtMHzvQSQmxdvMhEaAnBTM= Received: by 10.100.152.9 with SMTP id z9mr10983731and.1168375213357; Tue, 09 Jan 2007 12:40:13 -0800 (PST) Received: by 10.100.153.15 with HTTP; Tue, 9 Jan 2007 12:40:13 -0800 (PST) Message-ID: <30b660a20701091240m4c1b244l5bce8b2883f5db24@mail.gmail.com> Date: Tue, 9 Jan 2007 12:40:13 -0800 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] Re: Security and nationality In-Reply-To: <001e01c7327b$fc451320$6601a8c0@oemcomputer> MIME-Version: 1.0 References: <459AF83C.1030800@yahoo-inc.com> <20070106204934.GA10904@sources.org> <001e01c7327b$fc451320$6601a8c0@oemcomputer> X-Google-Sender-Auth: 2085b0fcb21ea855 X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1068950303==" Errors-To: ltru-bounces@ietf.org --===============1068950303== Content-Type: multipart/alternative; boundary="----=_Part_2724_11020432.1168375213286" ------=_Part_2724_11020432.1168375213286 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree On 1/7/07, Randy Presuhn wrote: > > Hi - > > As a technical contributor... > > > From: "Stephane Bortzmeyer" > > To: "Addison Phillips" > > Cc: > > Sent: Saturday, January 06, 2007 12:49 PM > > Subject: [Ltru] Re: Security and nationality > .... > > The proposal "It might be contrary to the privacy expectations of the > > user to send an Accept-Language header with the complete linguistic > > preferences of the user in every request." seems reasonable to me. The > > default behavior of Thunderbird is a concern to me, too. IMHO, we > > should warn implementors about privacy issues. > > > > (I do not suggest to make specific requirments such as "MUST NOT send > > the language preference by default" but I suggest to warn "There may > > be a problem here".) > ... > > This thread seems to center on potential problems in other specifications, > rather than intrinsic problems of language tags. Instead of talking about > specific headers in other protocols, I think we should stay generic. > If folks believe it is necessary to change the current text (I don't), how > about something like: > > Language tags used in, for example, content negotiation, like any > other information exchanged on the Internet, might be a source > of concern because they might be used to make inferences > about sender. > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_2724_11020432.1168375213286 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree

On 1/7/07, Randy Presuhn <randy_presuhn@mindspring.com> wrote:
Hi -

As a technical contributor...

> From: "Stephane Bortzmeyer" <bortzmeyer@nic.fr>
> To: "Addison Phillips" < addison@yahoo-inc.com>
> Cc: <ltru@ietf.org>
> Sent: Saturday, January 06, 2007 12:49 PM
> Subject: [Ltru] Re: Security and nationality
....
> The proposal "It might be contrary to the privacy expectations of the
> user to send an Accept-Language header with the complete linguistic
> preferences of the user in every request." seems reasonable to me. The
> default behavior of Thunderbird is a concern to me, too. IMHO, we
> should warn implementors about privacy issues.
>
> (I do not suggest to make specific requirments such as "MUST NOT send
> the language preference by default" but I suggest to warn "There may
> be a problem here".)
...

This thread seems to center on potential problems in other specifications,
rather than intrinsic problems of language tags.  Instead of talking about
specific headers in other protocols, I think we should stay generic.
If folks believe it is necessary to change the current text (I don't), how
about something like:

   Language tags used in, for example, content negotiation, like any
   other information exchanged on the Internet, might be a source
   of concern because they might be used to make inferences
   about sender.

Randy


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



--
Mark ------=_Part_2724_11020432.1168375213286-- --===============1068950303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1068950303==-- From ltru-bounces@ietf.org Thu Jan 11 06:32:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4yAA-0001gx-Fc; Thu, 11 Jan 2007 06:32:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4yA9-0001gK-Kl for ltru@ietf.org; Thu, 11 Jan 2007 06:32:05 -0500 Received: from mail6.microsoft.com ([205.248.106.32] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4yA7-0006oG-BB for ltru@ietf.org; Thu, 11 Jan 2007 06:32:05 -0500 Received: from mailout3.microsoft.com (157.57.217.10) by SVC-EXGWY-E803.partners.extranet.microsoft.com (10.251.24.244) with Microsoft SMTP Server id 8.0.685.24; Thu, 11 Jan 2007 03:32:02 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.141]) by mailout3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 03:31:18 -0800 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] Status of ISO 639-3? Date: Thu, 11 Jan 2007 03:29:26 -0800 Message-ID: <19A328037921AA42847A717566D1D6A10A362BB0@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Status of ISO 639-3? Thread-Index: AccyszURxYm6orjWTJCSvBD0/R5fLwCvo1pA From: Peter Constable To: Harald Alvestrand , X-OriginalArrivalTime: 11 Jan 2007 11:31:18.0283 (UTC) FILETIME=[02CD35B0:01C73574] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Does anyone know the status of 639-3, what changes have been made, and > plans/timelines for finishing it? The FDIS ballot was completed and the text of the standard was approved = for publication as an IS. Publication of the IS is ready to go pending = final preparation of the initial code table.=20 The issues being wrapped up on the code table have to do with making = better sense of what the entities are that have been coded in ISO = 639-1/-2 already -- needed since parts 1, 2, 3 and 5 of ISO 639 will = cover a common set of coded entities. This is being worked on by the ISO = 639-RA/JAC. Recent changes to ISO 639 that have been announced on = ietf-languages (e.g. "Bini" to "Bini; Edo", "Nahuatl" to "Nahuatl = languages", etc.) reflect some of that activity. There is still more of = this work to go; it's seen as a high priority to get this done quickly. Peter=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 11 08:05:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4zcl-0005CA-BE; Thu, 11 Jan 2007 08:05:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4zck-0005B1-EI for ltru@ietf.org; Thu, 11 Jan 2007 08:05:42 -0500 Received: from mail6.microsoft.com ([205.248.106.32] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4zci-0007wW-Tt for ltru@ietf.org; Thu, 11 Jan 2007 08:05:42 -0500 Received: from mailout3.microsoft.com (157.57.217.10) by SVC-EXGWY-E803.partners.extranet.microsoft.com (10.251.24.244) with Microsoft SMTP Server id 8.0.685.24; Thu, 11 Jan 2007 05:05:40 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.141]) by mailout3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 05:05:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Jan 2007 04:55:51 -0800 Message-ID: <19A328037921AA42847A717566D1D6A10A362BB3@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <30b660a20612181835o3c0a148bn8e9fc23e82f0386f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 639 coding wrt historic varieties (was RE: Request for variant subtag fr 16th-c 17th-c Resubmitted!) Thread-Index: AccjFl5LziNvDft/Sg2y6xzxnIlY/gSXiQZA From: Peter Constable To: , LTRU Working Group X-OriginalArrivalTime: 11 Jan 2007 13:05:40.0096 (UTC) FILETIME=[31815000:01C73581] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Subject: [Ltru] 639 coding wrt historic varieties (was RE: Request for variant subtag fr 16th-c 17th-c Resubmitted!) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1212031898==" Errors-To: ltru-bounces@ietf.org --===============1212031898== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogbWFyay5lZHdhcmQuZGF2aXNAZ21haWwuY29tIFttYWlsdG86bWFyay5lZHdhcmQuZGF2 aXNAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgTWFyayBEYXZpcw0KU2VudDogTW9uZGF5LCBEZWNl bWJlciAxOCwgMjAwNiA2OjM1IFBNDQoNCk1hcms6IFNvcnJ5IGZvciB0aGUgZGVsYXkgaW4gcmVz cG9uZGluZyB0byB0aGlzLg0KDQo+IFBldGVyLCBJJ20gYSBsaXR0bGUgYml0IGZ1enp5IG9uIHdo ZXJlIHRoZSBsaW5lcyB3ZXJlIA0KPiBkcmF3biB3aXRoIGhpc3RvcmljIHZlcnNpb25zIG9mIHRo ZSBzYW1lIGxhbmd1YWdlIGluIElTTy4gDQo+IFRoaXMgaXMgcmVsZXZhbnQgdG8gdGhlIExUUlUg Z3JvdXAgZm9yIElTTyA2MzktMywgc28gYW0gDQo+IGNjJ2luZyB0aGF0IGdyb3VwLg0KDQpFbnRp dGllcyBjb2RlZCBpbiA2MzktMSAoYXQgbGVhc3QsIGFueSBjb2RlZCBpbiA2MzktMSBwcmlvciB0 byA2MzktMikgd2VyZSBwcm9iYWJseSBkb25lIGZvciB0ZXJtaW5vbG9neSB3b3JrLCB3aGljaCB3 b3VsZCBhbG1vc3QgY2VydGFpbmx5IG1lYW4gdGhleSB3ZXJlIGRvbmUgZm9yIG1vZGVybiBmb3Jt cyBvZiBsYW5ndWFnZXMuDQoNClRoZSBoaXN0b3JpYyB2YXJpZXRpZXMgY29kZWQgaW4gNjM5LTIg cHJvYmFibHkgb3JpZ2luYXRlZCBpbiBNQVJDIGFuZCBoZW5jZSB3ZXJlIGRvbmUgb24gdGhlIGJh c2lzIG9mIHRoZSBwcmFjdGljZSBvZiBsaWJyYXJpYW5zIChhbmQgdGhvc2UgcHJpbWFyaWx5IGlu IFdlc3Rlcm4gbmF0aW9ucykuIEkgZG9uJ3Qga25vdyBvbiB3aGF0IGJhc2lzIHRoZXkgY2hvc2Ug dGhlIGJvdW5kYXJpZXMgdGhhdCB0aGV5IGRpZC4gDQoNCg0KPiBJIHRha2UgaXQgZnJvbSB5b3Vy IGRpc2N1c3Npb24gdGhhdCAiZnIiIG1lYW5zICpvbmx5KiANCj4gbW9kZXJuIEZyZW5jaCwgYW5k IHRoYXQgaWYgSSB3YW50IHRvIGhhdmUgYSB0YWcgZm9yIGFueSANCj4gRnJlbmNoLCBtb2Rlcm4g b3Igbm90LCBJIHdvdWxkIGhhdmUgdG8gdXNlIChmciBPUiBmcm0gDQo+IE9SIGZybykuIFNpbWls YXJseSwgaWYgSSB3YW50ZWQgYW55IEVuZ2xpc2gsIEkgd291bGQgDQo+IGhhdmUgdG8gdXNlIChl biBPUiBlbm0gT1IgYW5nKS4gDQoNClRoYXQncyBteSB1bmRlcnN0YW5kaW5nLiANCg0KU2luY2Ug NjM5LTEvLTIgb25seSBwcm92aWRlIEVuZ2xpc2ggYW5kIEZyZW5jaCBuYW1lcyBhcyBhIGd1aWRl IHRvIHRoZSBzZW1hbnRpY3Mgb2YgZWFjaCBjb2RlZCBlbnRpdHksIGl0IGlzbid0IGFsd2F5cyBj bGVhciBmcm9tIGEgZ2l2ZW4gZW50cnkgd2hhdCBpdCBtZWFucy4gVG8gZ2FpbiBhIG1vcmUgY29t cGxldGUgaWRlYSBvZiB0aGUgc2VtYW50aWNzIG9mIGVudHJpZXMsIHRoZXJlIGFyZSBhIGNvdXBs ZSBvZiB0aGluZ3Mgd2UgY2FuIGxvb2sgYXQ6IHdoYXQgZGlzdGluY3Rpb25zIGFyZSBtYWRlIHdp dGhpbiB0aGUgY29kZWQgc2V0LCBhbmQgaG93IGEgZ2l2ZW4gSUQgYmVlbiB1c2VkLiAoRm9yIHRo ZSBsYXR0ZXIsIE1BUkMgaXMgcGFydGljdWxhcmx5IHJlbGV2YW50IHNpbmNlIGl0IHdhcyB0aGUg c291cmNlIGZyb20gd2hpY2ggbW9zdCBvZiB0aGUgZW50aXRpZXMgY29kZWQgaW4gNjM5LTIuKQ0K DQpBcyBJIG1lbnRpb25lZCBhYm92ZSwgImZyIiB3YXMgb3JpZ2luYWxseSB1c2VkIGJ5IHRlcm1p bm9sb2dpc3RzLCBpbiB3aGljaCBjb250ZXh0IGl0IHZlcnkgbGlrZWx5IGhhcyBtZWFudCB0aGUg bW9kZXJuIHZhcmlldHkgb25seS4gVGhlIGNvcnJlc3BvbmRpbmcgYWxwaGEtMyBJRCAiZnJlIiB3 YXMgb3JpZ2luYWxseSB1c2VkIGJ5IGxpYnJhcmlhbnMuIFdoaWxlIGluIHRoYXQgY29udGV4dCBp dCdzIG1vcmUgbGlrZWx5IHRoYXQgdGhlIElEIHBvdGVudGlhbGx5IGNvdWxkIGhhdmUgYmVlbiB1 c2VkIGluIGEgd2F5IHRoYXQgZW5jb21wYXNzZWQgaGlzdG9yaWMgdmFyaWV0aWVzLCB0aGUgY29u dHJhc3RpdmUgY29kZWQgZW50aXRpZXMgImZybSIgYW5kICJmcm8iIHRoYXQgdGhleSBhbHNvIHVz ZWQgY2xlYXJseSBzdWdnZXN0cyB0aGF0IHRoYXQgd2FzIHByb2JhYmx5IG5vdCBob3cgdGhleSB1 c2VkIGl0LiBUaGUgTUFSQyBDb2RlIExpc3QgZm9yIExhbmd1YWdlcyAoaHR0cDovL3d3dy5sb2Mu Z292L21hcmMvbGFuZ3VhZ2VzLykgaXMgY29uc2lzdGVudCB3aXRoIHRoYXQ6IGluIGRlc2NyaWJp bmcgaG93ICJmcmUiIGlzIHVzZWQsIHRoZXkgZG9jdW1lbnQgaXQgYXMgZW5jb21wYXNzaW5nIHZh cmlldGllcyBmcm9tIGRpZmZlcmVudCByZWdpb25zLCBidXQgbm90IGhpc3RvcmljIHZhcmlldGll cy4NCg0KTm93LCBJIGFkbWl0IHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIGEgY29kZWQgZW50aXR5 IGxpa2UgImZyIiBjb3VsZCBlbmNvbXBhc3MgaGlzdG9yaWMgdmFyaWV0aWVzIGhhZCBub3Qgb2Nj dXJyZWQgdG8gbWUgdW50aWwgaXQgY2FtZSB1cCByZWNlbnRseSBpbiBpZXRmLWxhbmd1YWdlcyAv IExUUlUgKHdoaWNoZXZlciBpdCB3YXMpLiBBbmQgbXkgZ3Vlc3MgaXMgdGhhdCBpdCBoYXMgbmV2 ZXIgYmVlbiBjb25zaWRlcmVkIGJ5IHRoZSBKQUMgYXMgd2VsbDogdGhlIGlkZWEgdGhhdCBhbiBJ RCBtaWdodCBiZSB1c2VkIGZvciBtdWx0aXBsZSB2YXJpZXRpZXMgY2VydGFpbmx5IGV4aXN0ZWQg aW4gTUFSQywgYnV0IGl0IGFwcGVhcnMgdGhhdCB0aGF0IHdhcyBuZXZlciBkb25lIGluIE1BUkMg d2l0aCBoaXN0b3JpYyB2YXJpZXRpZXM7IGFuZCBhcGFydCBmcm9tIHRoYXQsIHRoZSBKQUMgaGFk IG5vIG9jY2FzaW9uIHRvIGRpc2N1c3MgYW4gSUQgZW5jb21wYXNzaW5nIG11bHRpcGxlIHZhcmll dGllcyAoZXhjZXB0IGZvciB0aGUgb2J2aW91cyBjYXNlIG9mIGNvbGxlY3Rpb25zKSB1bnRpbCBJ U08vQ0QgNjM5LTMgaW50cm9kdWNlZCBtYWNyb2xhbmd1YWdlcy4gQnV0IGdpdmVuIHRoZSBkaXN0 aW5jdGlvbnMgbWFkZSBpbiB0aGUgY29kZSBzZXQgYW5kIHRoZSB1c2FnZSBvZiA2MzktMS8tMiBJ RHMgYnkgdGVybWlub2xvZ2lzdHMgYW5kIGxpYnJhcmlhbnMsIEkgd291bGQgY29uY2x1ZGUgdGhh dCBJU08gNjM5IGN1cnJlbnRseSBkb2VzIG5vdCBoYXZlIGlkZW50aWZpZXJzIHRoYXQgYXJlIGlu dGVuZGVkIHRvIGVuY29tcGFzcyB2YXJpZXRpZXMgZnJvbSBtdWx0aXBsZSB0aW1lIGRlcHRocy4N Cg0KDQo+IE15IHF1ZXN0aW9uIGlzIGhvdyB0aGlzIGlzIG1hbmFnZWQgb3ZlciB0aW1lIGluIElT TywgDQo+IHNpbmNlIHRoZXJlIGFyZSBzaWduaWZpY2FudCBpbXBsaWNhdGlvbnMgZm9yIGxhbmd1 YWdlIHRhZ3MuDQoNCkl0J3MgYSBnb29kIHF1ZXN0aW9uLCBhbmQgb25lIEknbSBzdXJlIGhhc24n dCBiZWVuIGNvbnNpZGVyZWQgYnkgdGhlIEpBQy4NCg0KDQo+IExldCdzIHRha2UgQ3plY2gsIGZv ciBleGFtcGxlLCB3aGVyZSB3ZSBvbmx5IGN1cnJlbnRseSBoYXZlIA0KPiAnY3MnLiBJIHNlZSB0 aGUgZm9sbG93aW5nIHBvc3NpYmlsaXRpZXMuIA0KPg0KPiAxLiBUaGlzIG1lYW5zIG9ubHkgTW9k ZXJuIEN6ZWNoLg0KPiBUaGF0IGltcGxpZXMgdGhhdCB0aGVyZSBpcyBubyBjb2RlIGZvciBPbGQg Q3plY2gsIHNvIGlmIEkgDQo+IHdhbnQgdG8gdGFnIHNvbWV0aGluZyB3aXRoIHRoYXQsIEkgbmVl ZCB0byBwZXRpdGlvbiBJU08gDQo+IGZvciBhbiBsYW5ndWFnZSB0YWcgZm9yIE9sZCBDemVjaCAo bGV0J3Mgc2F5ICdjZXUnKS4gT25jZSANCj4gdGhhdCBpcyBhZGRlZCwgSSBjYW4gcmVmZXIgdG8g T2xkIEN6ZWNoLiANCj4NCj4gMi4gVGhpcyBjdXJyZW50bHkgbWVhbnMgYW55IEN6ZWNoLCBidXQg SVNPIG1heSBpbnRyb2R1Y2UgDQo+IGEgY29kZSBmb3IgT2xkIEN6ZWNoIChsZXQncyBzYXkgJ2Nl dScpLiANCg0KQXMgSSBtZW50aW9uZWQgYWJvdmUsIEkgdGhpbmsgZm9yIHVzZSBvZiA2MzktMSBp biB0ZXJtaW5vbG9neSBwcm9iYWJseSBvbmx5IG1vZGVybiB2YXJpZXRpZXMgd291bGQgaGF2ZSBi ZWVuIHJlbGV2YW50LiBBcyBmb3IgNjM5LTIsIHRoZSBmYWN0IHRoYXQgdGhlIHByYWN0aWNlIGhh cyBiZWVuIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBoaXN0b3JpYyB2YXJpZXRpZXMgY291bGQg YmUgc2VlbiB0byBzdWdnZXN0IHRoYXQgSURzIHJlZmVyIHNwZWNpZmljYWxseSB0byBtb2Rlcm4g dmFyaWV0aWVzIHVubGVzcyBvdGhlcndpc2Ugbm90ZWQuIE9uIHRoZSBvdGhlciBoYW5kLCBpdCdz IGVhc3kgdG8gaW1hZ2luZSB0aGF0IHRoZXJlIGFyZSB1c2VycyBvdXQgdGhlcmUgKGluY2x1ZGlu ZyBsaWJyYXJpYW5zKSB0aGF0IG1pZ2h0IGhhdmUgZG9uZSBvdGhlcndpc2UuDQoNCg0KPiBJIHNl ZSB0aHJlZSBwb3NzaWJsZSBhcHByb2FjaGVzOg0KPg0KPiAyYS4gVGhlIGRlbm90YXRpb24gb2Yg J2NzJyBpcyBjaGFuZ2VkIHRvIG1lYW4gb25seSBtb2Rlcm4gDQo+IEN6ZWNoLiBUaGlzIHdvdWxk IGJlIGEgYnJlYWtpbmcgY2hhbmdlIGZvciB0aGUgbGFuZ3VhZ2UgDQo+IHN1YnRhZyByZWdpc3Ry eSwgc2luY2UgdGhlIG1lYW5pbmcgb2YgYSBzdWJ0YWcgd291bGQgYmUgDQo+IG5hcnJvd2VkLCBp bnZhbGlkYXRpbmcgYW55IHRhZ3MgdGhhdCBoYWQgYSBicm9hZCANCj4gYXBwbGljYXRpb24uIFRo aXMgd291bGQgYmUgcmF0aGVyIGRpc3R1cmJpbmcsIHNpbmNlIHdlIGFyZSANCj4gZ3VhcmFudGVl aW5nIHN0YWJpbGl0eS4gDQoNCklmICJjcyIgd2VyZSBkZWVtZWQgdG8gZW5jb21wYXNzIGhpc3Rv cmljIEN6ZWNoIHZhcmlldGllcyBhcyB3ZWxsIGFzIG1vZGVybiwgdGhlbiB0aGlzIHdvdWxkIGJl IGEgYnJlYWtpbmcgY2hhbmdlIGZvciB1c2VycyBpbiBnZW5lcmFsLCBhbmQgc28gd291bGQgbm90 IGJlIGEgZ29vZCBpZGVhLg0KDQoNCj4gMmIuIFRoZSBkZW5vdGF0aW9uIG9mICdjcycgcmVtYWlu cyAiYW55IiBDemVjaCwgYW5kIHRvIGdldCANCj4gb25seSBtb2Rlcm4gQ3plY2ggSSB3b3VsZCBu ZWVkIHRvIHVzZSAoY3MgQU5EIE5PVCBjZXUpLiBOb3RlIA0KPiB3aGlsZSBPUiBjYW4gYmUgaGFu ZGxlZCB3aXRoIGEgbGlzdCwgYXMgcGVyIFJGQyA0NjQ3LCBBTkQgDQo+IE5PVCBjYW5ub3QuIFRo aXMsIGhvd2V2ZXIsIHdvdWxkIG5vdCBicmVhayBzdGFiaWxpdHkuIA0KDQpPZiBjb3Vyc2UsIGlm ICJjcyIgZW5jb21wYXNzZXMgYWxsIGhpc3RvcmljIHZhcmlldGllcywgdGhlbiBqdXN0IGFzIGFu IElEIGZvciBPbGQgQ3plY2ggY2FuIGJlIGFkZGVkLCBhbmQgSUQgZm9yIHNwZWNpZmljYWxseSBN b2Rlcm4gQ3plY2ggY2FuIGFsc28gYmUgYWRkZWQuDQoNCj4gMmMuIFRoZSBkZW5vdGF0aW9uIG9m ICdjcycgcmVtYWlucyAiYW55IiBDemVjaCwgY2V1IGJlY29tZXMgDQo+IGFuIGV4dGxhbmcuIFRo aXMgSSBzZWUgYXMgdGhlIGxlYXN0IHVucGxlYXNhbnQgb3V0Y29tZSwgYnV0IA0KPiBJIGNhbid0 IHRlbGwgaWYgd2hldGhlciB0aGlzIHdvdWxkIGJlIHRoZSBJU08gcG9saWN5Lg0KDQpJIHRoaW5r IGlmICJjcyIgd2VyZSBkZWVtZWQgdG8gZW5jb21wYXNzIGhpc3RvcmljIHZhcmlldGllcywgdGhl biBlZmZlY3RpdmVseSB0aGF0IG1ha2VzIGl0IGxpa2UgYSBtYWNyb2xhbmd1YWdlIGVudGl0eSwg ZXZlbiBpZiBlYWNoIG9mIHRoZSBpbmRpdmlkdWFsIGxhbmd1YWdlcyAobW9kZXJuLCBtaWRkbGUs IGV0Yy4pIGFyZSBub3QgY3VycmVudGx5IGNvZGVkLiBTbyB0aGVuLCBpZiBvbmUgb2YgdGhlIGhp c3RvcmljIHZhcmlldGllcyBkb2VzIGdldCBjb2RlZCBpbiA2MzksIHRoZW4gaXQgd291bGQgbWFr ZSBjb21wbGV0ZSBzZW5zZSB0byB0cmVhdCB0aGF0IGFzIGV4dGxhbmcgaW4gNDY0NmJpcy4NCg0K T2YgY291cnNlLCB0aGUgY3J1Y2lhbCBxdWVzdGlvbiBpcyB3aGV0aGVyICJjcyIgKG9yICJoaSIg b3IgImthIiBvciAuLi4pIGlzIGludGVuZGVkIHRvIG1lYW4gb25seSB0aGUgbW9kZXJuIGxhbmd1 YWdlIG9yIGlzIGludGVuZGVkIHRvIGVuY29tcGFzc2VzIG1vZGVybiBhbmQgaGlzdG9yaWMgdmFy aWV0aWVzLiBUaGlzIGlzIGFuIG9wZW4gcXVlc3Rpb24gdGhhdCBjb3VsZCBiZSBwdXQgdG8gdGhl IEpBQy4gDQoNCkknbSBzb21ld2hhdCBpbmNsaW5lZCB0byBzYXkgdGhhdCBhbGwgdGhlIGNvZGVk IGVudGl0aWVzIGluIDYzOSBzaG91bGQgYmUgdW5kZXJzdG9vZCB0byBiZSB0aGUgbW9kZXJuIHZh cmlldHkgdW5sZXNzIGV4cGxpY2l0bHkgaW5kaWNhdGVkIG90aGVyd2lzZS4gR2l2ZW4gdGhlIHZh c3QgbWFqb3JpdHkgb2YgZXhpc3RpbmcgdXNhZ2Ugb2YgSURzIGFuZCB0aGUgZXhpc3RpbmcgY29k aW5nIHByYWN0aWNlIG9mIGRpc3Rpbmd1aXNoaW5nIGhpc3RvcmljIHZhcmlldGllcyBmcm9tIG1v ZGVybiBvbmVzLCB0aGF0IHdvdWxkIG1haW50YWluIHRoZSBncmVhdGVzdCBsZXZlbCBvZiBjb25z aXN0ZW5jeS4gSSB0aGluayBpdCB3b3VsZCBiZSBjb25mdXNpbmcgZm9yIHVzZXJzIGlmIHRoZSBo aXN0b3JpYyB2YXJpZXRpZXMgd2VyZSB0cmVhdGVkIGluIGRpZmZlcmVudCB3YXlzIGZvciBkaWZm ZXJlbnQgY2FzZXMuIE9mIGNvdXJzZSwgdGhlcmUgd2lsbCBwcm9iYWJseSBiZSBzaXR1YXRpb25z IGluIHdoaWNoIHNvbWUgdXNlciB1c2VzIGFuIElEIGZvciBzb21ldGhpbmcgdGhhdCBhcmd1YWJs eSBpcyBhIGRpc3RpbmN0IGhpc3RvcmljIHZhcmlldHkgYW5kIHNob3VsZCBoYXZlIGEgZGlmZmVy ZW50IElEIChidXQgbm8gc2VwYXJhdGUgSUQgZXhpc3RzKS4gQnV0IEkgdGhpbmsgdGhhdCB3aGVu IHRoZXJlIGlzIGEgc2lnbmlmaWNhbnQgbmVlZCBmb3IgYW4gSUQgZm9yIGEgaGlzdG9yaWMgdmFy aWV0eSwgdXNlcnMgY2FuIHJlcXVlc3QgdGhlbSwgYW5kIHRoZSBKQUMgaXMgbGlrZWx5IHRvIGdy YW50IHRoZW0uIEknbSBvcGVuIHRvIG90aGVyIGlkZWFzIG9uIHRoaXMsIHRob3VnaC4NCg0KDQoN ClBldGVyIENvbnN0YWJsZQ0K --===============1212031898== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1212031898==-- From ltru-bounces@ietf.org Thu Jan 11 09:54:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51K2-0001ef-Ny; Thu, 11 Jan 2007 09:54:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51K1-0001eY-0p for ltru@ietf.org; Thu, 11 Jan 2007 09:54:29 -0500 Received: from an-out-0708.google.com ([209.85.132.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H51Jx-0003e3-Ns for ltru@ietf.org; Thu, 11 Jan 2007 09:54:29 -0500 Received: by an-out-0708.google.com with SMTP id d30so313043and for ; Thu, 11 Jan 2007 06:54:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=HXdDMlBer6XYyu4ujB+vQFs9hvB1gyENQyilRfTlYRIRWuz6OqhMCoNtUvx20fjpsfOgS9fJVizBZjyLF6uE8FO7ADASTw7CPBdqNjVoxNBaQj8sU9UrFO8To+UcbiyuiKNIy09KwzF20QHvN4ds/E9g6mOwI74AUUPlzmA2sa8= Received: by 10.100.33.14 with SMTP id g14mr1071093ang.1168527265482; Thu, 11 Jan 2007 06:54:25 -0800 (PST) Received: by 10.100.153.15 with HTTP; Thu, 11 Jan 2007 06:54:25 -0800 (PST) Message-ID: <30b660a20701110654s439c22c0t903038e0b6c53867@mail.gmail.com> Date: Thu, 11 Jan 2007 06:54:25 -0800 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] 639 coding wrt historic varieties (was RE: Request for variant subtag fr 16th-c 17th-c Resubmitted!) In-Reply-To: <19A328037921AA42847A717566D1D6A10A362BB3@RED-MSG-42.redmond.corp.microsoft.com> MIME-Version: 1.0 References: <30b660a20612181835o3c0a148bn8e9fc23e82f0386f@mail.gmail.com> <19A328037921AA42847A717566D1D6A10A362BB3@RED-MSG-42.redmond.corp.microsoft.com> X-Google-Sender-Auth: e4a0d3bf73459d36 X-Spam-Score: 0.3 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: ietf-languages@iana.org, LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0075263146==" Errors-To: ltru-bounces@ietf.org --===============0075263146== Content-Type: multipart/alternative; boundary="----=_Part_3512_16291357.1168527265424" ------=_Part_3512_16291357.1168527265424 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for the detailed responses, which all sound sensible. Can you put the "crucial question" to the JAC, so we can get some clarity on how to proceed? I'm inclined to agree with your inclination "to say that all the coded entities in 639 should be understood to be the modern variety unless explicitly indicated otherwise". (The boundaries for the modern languages will come up for the ietf languages group, for example, if someone tries to register a variant for 12th century Czech. We will need to know that that requires first a language subtag for "Old Czech (ca. 1000-1400)" to be encoded as a prefix for that, and route the applicant to the JAC.) Mark On 1/11/07, Peter Constable wrote: > > From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On > Behalf Of Mark Davis > Sent: Monday, December 18, 2006 6:35 PM > > Mark: Sorry for the delay in responding to this. > > > Peter, I'm a little bit fuzzy on where the lines were > > drawn with historic versions of the same language in ISO. > > This is relevant to the LTRU group for ISO 639-3, so am > > cc'ing that group. > > Entities coded in 639-1 (at least, any coded in 639-1 prior to 639-2) were > probably done for terminology work, which would almost certainly mean they > were done for modern forms of languages. > > The historic varieties coded in 639-2 probably originated in MARC and > hence were done on the basis of the practice of librarians (and those > primarily in Western nations). I don't know on what basis they chose the > boundaries that they did. > > > > I take it from your discussion that "fr" means *only* > > modern French, and that if I want to have a tag for any > > French, modern or not, I would have to use (fr OR frm > > OR fro). Similarly, if I wanted any English, I would > > have to use (en OR enm OR ang). > > That's my understanding. > > Since 639-1/-2 only provide English and French names as a guide to the > semantics of each coded entity, it isn't always clear from a given entry > what it means. To gain a more complete idea of the semantics of entries, > there are a couple of things we can look at: what distinctions are made > within the coded set, and how a given ID been used. (For the latter, MARC is > particularly relevant since it was the source from which most of the > entities coded in 639-2.) > > As I mentioned above, "fr" was originally used by terminologists, in which > context it very likely has meant the modern variety only. The corresponding > alpha-3 ID "fre" was originally used by librarians. While in that context > it's more likely that the ID potentially could have been used in a way that > encompassed historic varieties, the contrastive coded entities "frm" and > "fro" that they also used clearly suggests that that was probably not how > they used it. The MARC Code List for Languages ( > http://www.loc.gov/marc/languages/) is consistent with that: in describing > how "fre" is used, they document it as encompassing varieties from different > regions, but not historic varieties. > > Now, I admit the question of whether a coded entity like "fr" could > encompass historic varieties had not occurred to me until it came up > recently in ietf-languages / LTRU (whichever it was). And my guess is that > it has never been considered by the JAC as well: the idea that an ID might > be used for multiple varieties certainly existed in MARC, but it appears > that that was never done in MARC with historic varieties; and apart from > that, the JAC had no occasion to discuss an ID encompassing multiple > varieties (except for the obvious case of collections) until ISO/CD 639-3 > introduced macrolanguages. But given the distinctions made in the code set > and the usage of 639-1/-2 IDs by terminologists and librarians, I would > conclude that ISO 639 currently does not have identifiers that are intended > to encompass varieties from multiple time depths. > > > > My question is how this is managed over time in ISO, > > since there are significant implications for language tags. > > It's a good question, and one I'm sure hasn't been considered by the JAC. > > > > Let's take Czech, for example, where we only currently have > > 'cs'. I see the following possibilities. > > > > 1. This means only Modern Czech. > > That implies that there is no code for Old Czech, so if I > > want to tag something with that, I need to petition ISO > > for an language tag for Old Czech (let's say 'ceu'). Once > > that is added, I can refer to Old Czech. > > > > 2. This currently means any Czech, but ISO may introduce > > a code for Old Czech (let's say 'ceu'). > > As I mentioned above, I think for use of 639-1 in terminology probably > only modern varieties would have been relevant. As for 639-2, the fact that > the practice has been to differentiate between historic varieties could be > seen to suggest that IDs refer specifically to modern varieties unless > otherwise noted. On the other hand, it's easy to imagine that there are > users out there (including librarians) that might have done otherwise. > > > > I see three possible approaches: > > > > 2a. The denotation of 'cs' is changed to mean only modern > > Czech. This would be a breaking change for the language > > subtag registry, since the meaning of a subtag would be > > narrowed, invalidating any tags that had a broad > > application. This would be rather disturbing, since we are > > guaranteeing stability. > > If "cs" were deemed to encompass historic Czech varieties as well as > modern, then this would be a breaking change for users in general, and so > would not be a good idea. > > > > 2b. The denotation of 'cs' remains "any" Czech, and to get > > only modern Czech I would need to use (cs AND NOT ceu). Note > > while OR can be handled with a list, as per RFC 4647, AND > > NOT cannot. This, however, would not break stability. > > Of course, if "cs" encompasses all historic varieties, then just as an ID > for Old Czech can be added, and ID for specifically Modern Czech can also be > added. > > > 2c. The denotation of 'cs' remains "any" Czech, ceu becomes > > an extlang. This I see as the least unpleasant outcome, but > > I can't tell if whether this would be the ISO policy. > > I think if "cs" were deemed to encompass historic varieties, then > effectively that makes it like a macrolanguage entity, even if each of the > individual languages (modern, middle, etc.) are not currently coded. So > then, if one of the historic varieties does get coded in 639, then it would > make complete sense to treat that as extlang in 4646bis. > > Of course, the crucial question is whether "cs" (or "hi" or "ka" or ...) > is intended to mean only the modern language or is intended to encompasses > modern and historic varieties. This is an open question that could be put to > the JAC. > > I'm somewhat inclined to say that all the coded entities in 639 should be > understood to be the modern variety unless explicitly indicated otherwise. > Given the vast majority of existing usage of IDs and the existing coding > practice of distinguishing historic varieties from modern ones, that would > maintain the greatest level of consistency. I think it would be confusing > for users if the historic varieties were treated in different ways for > different cases. Of course, there will probably be situations in which some > user uses an ID for something that arguably is a distinct historic variety > and should have a different ID (but no separate ID exists). But I think that > when there is a significant need for an ID for a historic variety, users can > request them, and the JAC is likely to grant them. I'm open to other ideas > on this, though. > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > -- Mark ------=_Part_3512_16291357.1168527265424 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for the detailed responses, which all sound sensible. Can you put the "crucial question" to the JAC, so we can get some clarity on how to proceed?

I'm inclined to agree with your inclination "to say that all the coded entities in 639 should be understood to be the modern variety unless explicitly indicated otherwise". (The boundaries for the modern languages will come up for the ietf languages group, for example, if someone tries to register a variant for 12th century Czech. We will need to know that that requires first a language subtag for "Old Czech (ca. 1000-1400)" to be encoded as a prefix for that, and route the applicant to the JAC.)

Mark

On 1/11/07, Peter Constable <petercon@microsoft.com> wrote:
From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Behalf Of Mark Davis
Sent: Monday, December 18, 2006 6:35 PM

Mark: Sorry for the delay in responding to this.

> Peter, I'm a little bit fuzzy on where the lines were
> drawn with historic versions of the same language in ISO.
> This is relevant to the LTRU group for ISO 639-3, so am
> cc'ing that group.

Entities coded in 639-1 (at least, any coded in 639-1 prior to 639-2) were probably done for terminology work, which would almost certainly mean they were done for modern forms of languages.

The historic varieties coded in 639-2 probably originated in MARC and hence were done on the basis of the practice of librarians (and those primarily in Western nations). I don't know on what basis they chose the boundaries that they did.


> I take it from your discussion that "fr" means *only*
> modern French, and that if I want to have a tag for any
> French, modern or not, I would have to use (fr OR frm
> OR fro). Similarly, if I wanted any English, I would
> have to use (en OR enm OR ang).

That's my understanding.

Since 639-1/-2 only provide English and French names as a guide to the semantics of each coded entity, it isn't always clear from a given entry what it means. To gain a more complete idea of the semantics of entries, there are a couple of things we can look at: what distinctions are made within the coded set, and how a given ID been used. (For the latter, MARC is particularly relevant since it was the source from which most of the entities coded in 639-2.)

As I mentioned above, "fr" was originally used by terminologists, in which context it very likely has meant the modern variety only. The corresponding alpha-3 ID "fre" was originally used by librarians. While in that context it's more likely that the ID potentially could have been used in a way that encompassed historic varieties, the contrastive coded entities "frm" and "fro" that they also used clearly suggests that that was probably not how they used it. The MARC Code List for Languages ( http://www.loc.gov/marc/languages/) is consistent with that: in describing how "fre" is used, they document it as encompassing varieties from different regions, but not historic varieties.

Now, I admit the question of whether a coded entity like "fr" could encompass historic varieties had not occurred to me until it came up recently in ietf-languages / LTRU (whichever it was). And my guess is that it has never been considered by the JAC as well: the idea that an ID might be used for multiple varieties certainly existed in MARC, but it appears that that was never done in MARC with historic varieties; and apart from that, the JAC had no occasion to discuss an ID encompassing multiple varieties (except for the obvious case of collections) until ISO/CD 639-3 introduced macrolanguages. But given the distinctions made in the code set and the usage of 639-1/-2 IDs by terminologists and librarians, I would conclude that ISO 639 currently does not have identifiers that are intended to encompass varieties from multiple time depths.


> My question is how this is managed over time in ISO,
> since there are significant implications for language tags.

It's a good question, and one I'm sure hasn't been considered by the JAC.


> Let's take Czech, for example, where we only currently have
> 'cs'. I see the following possibilities.
>
> 1. This means only Modern Czech.
> That implies that there is no code for Old Czech, so if I
> want to tag something with that, I need to petition ISO
> for an language tag for Old Czech (let's say 'ceu'). Once
> that is added, I can refer to Old Czech.
>
> 2. This currently means any Czech, but ISO may introduce
> a code for Old Czech (let's say 'ceu').

As I mentioned above, I think for use of 639-1 in terminology probably only modern varieties would have been relevant. As for 639-2, the fact that the practice has been to differentiate between historic varieties could be seen to suggest that IDs refer specifically to modern varieties unless otherwise noted. On the other hand, it's easy to imagine that there are users out there (including librarians) that might have done otherwise.


> I see three possible approaches:
>
> 2a. The denotation of 'cs' is changed to mean only modern
> Czech. This would be a breaking change for the language
> subtag registry, since the meaning of a subtag would be
> narrowed, invalidating any tags that had a broad
> application. This would be rather disturbing, since we are
> guaranteeing stability.

If "cs" were deemed to encompass historic Czech varieties as well as modern, then this would be a breaking change for users in general, and so would not be a good idea.


> 2b. The denotation of 'cs' remains "any" Czech, and to get
> only modern Czech I would need to use (cs AND NOT ceu). Note
> while OR can be handled with a list, as per RFC 4647, AND
> NOT cannot. This, however, would not break stability.

Of course, if "cs" encompasses all historic varieties, then just as an ID for Old Czech can be added, and ID for specifically Modern Czech can also be added.

> 2c. The denotation of 'cs' remains "any" Czech, ceu becomes
> an extlang. This I see as the least unpleasant outcome, but
> I can't tell if whether this would be the ISO policy.

I think if "cs" were deemed to encompass historic varieties, then effectively that makes it like a macrolanguage entity, even if each of the individual languages (modern, middle, etc.) are not currently coded. So then, if one of the historic varieties does get coded in 639, then it would make complete sense to treat that as extlang in 4646bis.

Of course, the crucial question is whether "cs" (or "hi" or "ka" or ...) is intended to mean only the modern language or is intended to encompasses modern and historic varieties. This is an open question that could be put to the JAC.

I'm somewhat inclined to say that all the coded entities in 639 should be understood to be the modern variety unless explicitly indicated otherwise. Given the vast majority of existing usage of IDs and the existing coding practice of distinguishing historic varieties from modern ones, that would maintain the greatest level of consistency. I think it would be confusing for users if the historic varieties were treated in different ways for different cases. Of course, there will probably be situations in which some user uses an ID for something that arguably is a distinct historic variety and should have a different ID (but no separate ID exists). But I think that when there is a significant need for an ID for a historic variety, users can request them, and the JAC is likely to grant them. I'm open to other ideas on this, though.



Peter Constable

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





--
Mark ------=_Part_3512_16291357.1168527265424-- --===============0075263146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0075263146==-- From ltru-bounces@ietf.org Thu Jan 11 16:02:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H573U-00013k-0K; Thu, 11 Jan 2007 16:01:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H573S-00013F-6N for ltru@ietf.org; Thu, 11 Jan 2007 16:01:46 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H573Q-0002OZ-OR for ltru@ietf.org; Thu, 11 Jan 2007 16:01:46 -0500 Received: by ug-out-1314.google.com with SMTP id 72so560041ugd for ; Thu, 11 Jan 2007 13:01:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hOkotj9ngwxEnpQYUl3UE4X+P5dtXiyJ43euyY0gI9VKRr38bwpx1FUmmiZaoV6eT8f9erYy4ljQ0Vps2QmqTFmVS2AbCoJTBRrwYU5WXxh9GbmJqPTtLp/xY2DIfZoSezB3WgkZ86Jxw19lZuZ1f7msLPJiyr7AORE3s3CjKcg= Received: by 10.78.180.16 with SMTP id c16mr710804huf.1168549303131; Thu, 11 Jan 2007 13:01:43 -0800 (PST) Received: by 10.78.151.14 with HTTP; Thu, 11 Jan 2007 13:01:43 -0800 (PST) Message-ID: <6d99d1fd0701111301x3b82bd38jc87ddfa532f1bca4@mail.gmail.com> Date: Thu, 11 Jan 2007 15:01:43 -0600 From: "David Starner" To: "Mark Davis" Subject: Re: [Ltru] 639 coding wrt historic varieties (was RE: Request for variant subtag fr 16th-c 17th-c Resubmitted!) In-Reply-To: <30b660a20701110654s439c22c0t903038e0b6c53867@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <30b660a20612181835o3c0a148bn8e9fc23e82f0386f@mail.gmail.com> <19A328037921AA42847A717566D1D6A10A362BB3@RED-MSG-42.redmond.corp.microsoft.com> <30b660a20701110654s439c22c0t903038e0b6c53867@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ietf-languages@iana.org, LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 1/11/07, Mark Davis wrote: > I'm inclined to agree with your inclination "to say that all the coded > entities in 639 should be understood to be the modern variety unless > explicitly indicated otherwise". (The boundaries for the modern languages > will come up for the ietf languages group, for example, if someone tries to > register a variant for 12th century Czech. We will need to know that that > requires first a language subtag for "Old Czech (ca. 1000-1400)" to be > encoded as a prefix for that, and route the applicant to the JAC.) There's several problems I see. The chronological lines between languages are as arbitrary as any, and there is no way to predict when the committee would draw the line between modern and pre-modern Czech. So a user _cannot_ know whether cs applies to their 15th century Czech books or not without bringing it up to the committee. Secondly, this breaks at least some current usage. For example, I tagged "Primitive & mediaeval Japanese texts" (10th-12th century Japanese) and "Ars grammaticae Iaponicae linguae" (17th century Japanese) as including ja when entering them into the Distributed Proofreaders database. When it comes to Project Gutenberg, it will be entered as ja. The LoC seems to have entered the first as eng, despite having one volume of ja-Latn, but I'm sure there's medieval Japanese in a library database marked as ja somewhere. Third, right now, the tagging for ancient languages is woefully insufficient. Unless someone's willing to put a lot of work into cataloging recorded ancient languages, a library like PG will end up using the modern language tags for ancient languages instead of fighting for dozens of new tags. To follow this path involves dozens of new tags, which probably won't successfully be created piece-meal. PS. I'll point out this has slightly absurd results when applied to la. I think we can assume that la was designed to apply to Classical Latin, and not (not just?) the modern variety. PS. #2 I can't think of any way this affects tlh. Isn't everyone happy about that? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 12 01:50:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5GEn-0006Ux-9a; Fri, 12 Jan 2007 01:50:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5GEl-0006Ln-7Y for ltru@ietf.org; Fri, 12 Jan 2007 01:50:03 -0500 Received: from mta16.mail.adelphia.net ([68.168.78.211] helo=mta16.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5GEj-0001CK-Sa for ltru@ietf.org; Fri, 12 Jan 2007 01:50:03 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070112063331.WWWI2311.mta16.adelphia.net@DGBP7M81> for ; Fri, 12 Jan 2007 01:33:31 -0500 Message-ID: <005201c73615$de07e160$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 11 Jan 2007 22:49:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [Ltru] Last few questions for draft-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Spurred on by the great outpouring of responses (ahem) to my earlier questions, I'm just about ready to crank out draft-ietf-ltru-4645-01. (Not -02 as I've said before; I'd forgotten over the months that I never submitted -01.) Some of the resolved issues are as follows: - Whether to include all names from ISO 639-3 or, in cases where inverted/uninverted pairs exist, only one or the other. Answer: include all. - Whether to create a new Reference-Name field. Answer: no. - Whether to make the first Description field equivalent to the ISO 639-3 reference name, when one exists. Answer: yes, at least in practice. Specifying this as normative or not is up to RFC 4646bis. - Whether to split compound ISO 15924-based Description fields into multiple lines. Answer: yes, but only for those names indicated in the post I sent to the WG on January 3. Here are the last few questions I still have, along with the default answers I will apply for each unless somebody states otherwise, and quickly: - ISO 639-2 has "Castilian" with one L, while ISO 639-3 has "Castillian" with two L's. Use one or the other, or both? (Default: Holding my nose, I say "only the two-L version" purely because it is the 639-3 reference name. Personally I greatly prefer the one-L spelling, and hope the 639-2 and 639-3 people can get together and agree on a spelling.) - ISO 639-2 has "Galician" while ISO 639-3 still has "Gallegan." Use one or the other, or both? (Default: Both.) - ISO 639-3 has parenthetical comments after some names, such as "Gaelic (Scots)" and "Ainu (Japan)" and "Gbaya (Central African Republic)", where ISO 639-2 has simply "Gaelic" and "Ainu" and "Gbaya." Use one or the other, or both? (Default: Both.) - For the macrolanguages Dogri, Konkani, Malay, and Swahili, ISO 639-3 has the parenthetical comment "(generic)", while for the individual languages of the same name (plus Zande) it has the comment "(specific)". Use these? (Default: No, rip them out. There will be no name conflicts since the former is always a primary language subtag and the latter an extlang. In the case of Zande there is no conflict with the corresponding collection code "Zande languages.") - Should we maintain the relative order of existing Description fields and add new 639-3-based descriptions at the end, except that the reference name always becomes the first Description? (Default: Yes.) - In an early update, IANA added the 3-letter language subtags "anp" and "frr" among the 2-letter subtags. Traditionally the 2-letter subtags come first, followed by the 3-letter ones. RFC 4646 says the order of language subtags doesn't matter as long as all are together in one group. Should we move "anp" and "frr" back among the 3-letter subtags where humans might expect them, or leave them as is? (Default: Move them.) - Section 2.4 of draft-4645bis-00 has the sentence, "Grandfathered tags cannot be generated from a combination of valid subtags, while 'redundant' tags can be." This is not strictly true; "zh" and "min" are valid subtags but the combination is not semantically equivalent to the grandfathered tag "zh-min." Should this be changed almost imperceptibly to read, "... cannot be generated from a valid combination of subtags"? (Default: Yes.) If you have comments on any of this, please speak up soon. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 12 08:14:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5MF0-0007MQ-Ec; Fri, 12 Jan 2007 08:14:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5MEz-0007KR-42 for ltru@lists.ietf.org; Fri, 12 Jan 2007 08:14:41 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5MEw-000411-LR for ltru@lists.ietf.org; Fri, 12 Jan 2007 08:14:41 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H5MEk-00052A-An for ltru@lists.ietf.org; Fri, 12 Jan 2007 14:14:26 +0100 Received: from d252161.dialin.hansenet.de ([80.171.252.161]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Jan 2007 14:14:26 +0100 Received: from nobody by d252161.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Jan 2007 14:14:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 12 Jan 2007 14:12:36 +0100 Organization: Lines: 68 Message-ID: <45A78944.6E26@xyzzy.claranet.de> References: <005201c73615$de07e160$6601a8c0@DGBP7M81> 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: d252161.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Subject: [Ltru] Re: Last few questions for draft-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > ISO 639-2 has "Castilian" with one L, while ISO 639-3 has "Castillian" > with two L's. Use one or the other, or both? (Default: Holding my > nose, I say "only the two-L version" purely because it is the 639-3 > reference name. Personally I greatly prefer the one-L spelling, and > hope the 639-2 and 639-3 people can get together and agree on a > spelling.) +1 Google has about 1,140,000 hits for one L, and 280,000 for LL. MW has Castlian and no Castillian. Maybe it's a typo in 639-3, they should fix it. Until then use their spelling. > ISO 639-2 has "Galician" while ISO 639-3 still has "Gallegan." Use > one or the other, or both? (Default: Both.) Ugh. I hope that Galician wins. Until then "both" is fine. > ISO 639-3 has parenthetical comments after some names, such as "Gaelic > (Scots)" and "Ainu (Japan)" and "Gbaya (Central African Republic)", > where ISO 639-2 has simply "Gaelic" and "Ainu" and "Gbaya." Use one or > the other, or both? (Default: Both.) The 639-3 name with comments is better. > For the macrolanguages Dogri, Konkani, Malay, and Swahili, ISO 639-3 > has the parenthetical comment "(generic)", while for the individual > languages of the same name (plus Zande) it has the comment "(specific)". > Use these? (Default: No, rip them out. There will be no name conflicts > since the former is always a primary language subtag and the latter an > extlang. In the case of Zande there is no conflict with the > corresponding collection code "Zande languages.") +1 > Should we maintain the relative order of existing Description fields > and add new 639-3-based descriptions at the end, except that the > reference name always becomes the first Description? (Default: Yes.) If you like it that way... what you get will be 639-3 reference before 639-1/2 descriptions before other 639-3 descriptions (modulo duplicates) I'd prefer a block of 639-3 descriptions automatically starting with the reference name before anything else found in 639-1/2, but that's mostly a matter of taste. Maybe my preference is better for maintenance (?) > In an early update, IANA added the 3-letter language subtags "anp" and > "frr" among the 2-letter subtags. Traditionally the 2-letter subtags > come first, followed by the 3-letter ones. RFC 4646 says the order of > language subtags doesn't matter as long as all are together in one > group. Should we move "anp" and "frr" back among the 3-letter subtags > where humans might expect them, or leave them as is? (Default: Move > them.) +1 > Section 2.4 of draft-4645bis-00 has the sentence, "Grandfathered tags > cannot be generated from a combination of valid subtags, while > 'redundant' tags can be." This is not strictly true; "zh" and "min" are > valid subtags but the combination is not semantically equivalent to the > grandfathered tag "zh-min." Should this be changed almost imperceptibly > to read, "... cannot be generated from a valid combination of subtags"? > (Default: Yes.) +1 Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 12 08:48:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Mlk-0002rq-JK; Fri, 12 Jan 2007 08:48:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55lJ-0008L2-4o for ltru@ietf.org; Thu, 11 Jan 2007 14:38:57 -0500 Received: from bay0-omc2-s22.bay0.hotmail.com ([65.54.246.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H55lF-0005HL-Ny for ltru@ietf.org; Thu, 11 Jan 2007 14:38:57 -0500 Received: from hotmail.com ([65.54.169.24]) by bay0-omc2-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 11 Jan 2007 11:38:53 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Jan 2007 11:38:52 -0800 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Thu, 11 Jan 2007 19:38:52 GMT X-Originating-IP: [209.133.185.129] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com In-Reply-To: <30b660a20701110654s439c22c0t903038e0b6c53867@mail.gmail.com> From: "CE Whitehead" To: mark.davis@icu-project.org, petercon@microsoft.com Bcc: Subject: Re: [Ltru] 639 coding wrt historic varieties (was RE: Request forvariant subtag Date: Thu, 11 Jan 2007 14:38:52 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 11 Jan 2007 19:38:52.0980 (UTC) FILETIME=[1FF5B740:01C735B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-Mailman-Approved-At: Fri, 12 Jan 2007 08:48:32 -0500 Cc: ietf-languages@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org >Thanks for the detailed responses, which all sound sensible. Can you put >the >"crucial question" to the JAC, so we can get some clarity on how to >proceed? I guess we could question the JAC > >I'm inclined to agree with your inclination "to say that all the coded >entities in 639 should be understood to be the modern variety unless >explicitly indicated otherwise". >> >> > I take it from your discussion that "fr" means *only* >> > modern French, and that if I want to have a tag for any >> > French, modern or not, I would have to use (fr OR frm >> > OR fro). Similarly, if I wanted any English, I would >> > have to use (en OR enm OR ang). >> >>That's my understanding. >> >>Since 639-1/-2 only provide English and French names as a guide to the >>semantics of each coded entity, it isn't always clear from a given entry >>what it means. To gain a more complete idea of the semantics of entries, >>there are a couple of things we can look at: what distinctions are made >>within the coded set, and how a given ID been used. (For the latter, MARC >>is >>particularly relevant since it was the source from which most of the >>entities coded in 639-2.) >> >>As I mentioned above, "fr" was originally used by terminologists, in which >>context it very likely has meant the modern variety only. The >>corresponding >>alpha-3 ID "fre" was originally used by librarians. While in that context >>it's more likely that the ID potentially could have been used in a way >>that >>encompassed historic varieties, the contrastive coded entities "frm" and >>"fro" that they also used clearly suggests that that was probably not how >>they used it. The MARC Code List for Languages ( >>http://www.loc.gov/marc/languages/) is consistent with that: in describing >>how "fre" is used, they document it as encompassing varieties from >>different >>regions, but not historic varieties. Two things: 1. In my French studies we used Old French to refer to Old French. It is semi-comprehensible but not completely so to speakers of modern French. We rarely talked about Middle French however although the term is there. However all these could be encompassed (albeit somewhat loosely, laxly, or something) under the larger term French but this is an extension of course of the meaning of French which actually means a very specific modern language. 2. The regional varieties sometimes can be as different as the historical ones. I guess I need to find out which regional varieties were encompassed by fre, by checking the document at http://www.loc.gov/marc/languages/ (can I find out there?) and getting back to you. I suppose one option would be to have a tag fr-ext and then that would be more like a macro tag for an extended meaning of French and then you could have fr-ext-16s fr-ext-17s fr-ext-frm but that is bizarre and the variant form ext extending the French would be nesting (I guess, or something?) which I understand is not to be done. So we might need some new tag but not fr with a variant ext then; and not fre which aready means something else; fra I do not like either; and fr by itself of course has only its specific meaning perhaps frx? I'm not sure what I think of that. --C. E. Whitehead cewcathar@hotmail.com _________________________________________________________________ The MSN Entertainment Guide to Golden Globes is here. Get all the scoop. http://tv.msn.com/tv/globes2007/?icid=nctagline2 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 12 09:14:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NAS-00005s-Sq; Fri, 12 Jan 2007 09:14:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NAR-00005n-5N for ltru@ietf.org; Fri, 12 Jan 2007 09:14:03 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5NAO-0002iL-Sy for ltru@ietf.org; Fri, 12 Jan 2007 09:14:03 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H5NAO-00078Y-7G; Fri, 12 Jan 2007 09:14:00 -0500 Date: Fri, 12 Jan 2007 09:14:00 -0500 To: Doug Ewell Subject: Re: [Ltru] Last few questions for draft-4645bis-01 Message-ID: <20070112141400.GA8354@ccil.org> References: <005201c73615$de07e160$6601a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005201c73615$de07e160$6601a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Here are the last few questions I still have, along with the default > answers I will apply for each unless somebody states otherwise, and > quickly: I agree with all your defaults, except: > - For the macrolanguages Dogri, Konkani, Malay, and Swahili, ISO 639-3 > has the parenthetical comment "(generic)", while for the individual > languages of the same name (plus Zande) it has the comment "(specific)". > Use these? (Default: No, rip them out. There will be no name conflicts > since the former is always a primary language subtag and the latter an > extlang. In the case of Zande there is no conflict with the > corresponding collection code "Zande languages.") I'm against this, since it seems to me that it's likely to recur and we will have to strip more prefixes. For example, if Foovian (hypothetical) has a deviant Bazzian dialect, and 639-3/RA decides that Bazzian is really a separate language, we may wind up with "Foovian (generic)", "Foovian (specific)" and "Bazzian". We would therefore have to put the rule for stripping these things directly into 4646bis. Worse yet, 639-3/RA may introduce a macrolanguage that encompasses existing languages. For example, if it turns out that a code is needed that encompasses the larger Toto language and its close but smaller relatives Titi, Tata, and Tutu (all hypothetical), the most natural name for this macrolanguage may turn out to be "Toto (generic)", with a concomitant name change of "Toto" to "Toto (specific)". Remember that macrolanguages represent facts on the ground about how people talk about languages. Now, however, Toto (specific), Titi, Tata, and Tutu cannot and will not be made into extlangs, because they already have language subtags which we cannot invalidate. So if we strip the generic/specific markers, we wind up with two languages called "Toto". Very bad. So let's leave these names, like all other names, strictly alone. If we can swallow the Latin-1 stand-alone acute accent, we can swallow anything. -- John Cowan http://www.ccil.org/~cowan Charles li reis, nostre emperesdre magnes, Set anz totz pleinz ad ested in Espagnes. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 12 10:08:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5O1F-0000kz-To; Fri, 12 Jan 2007 10:08:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5O1F-0000kt-BB for ltru@ietf.org; Fri, 12 Jan 2007 10:08:37 -0500 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5O1D-0000Zi-TT for ltru@ietf.org; Fri, 12 Jan 2007 10:08:37 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070112145657.UBZX25578.mta15.adelphia.net@DGBP7M81>; Fri, 12 Jan 2007 09:56:57 -0500 Message-ID: <008101c7365b$87ed53f0$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005201c73615$de07e160$6601a8c0@DGBP7M81> <20070112141400.GA8354@ccil.org> Subject: Re: [Ltru] Last few questions for draft-4645bis-01 Date: Fri, 12 Jan 2007 07:08:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Now, however, Toto (specific), Titi, Tata, and Tutu cannot and will > not be made into extlangs, because they already have language subtags > which we cannot invalidate. So if we strip the generic/specific > markers, we wind up with two languages called "Toto". Very bad. We already have the potential for this in Dimli and Kirmanjki, two alternative names for "zza" that are also the names for the individual languages "diq" and "kiu". Right now there is no conflict, but if "diq" and "kiu" were not encompassed we would have a problem. > So let's leave these names, like all other names, strictly alone. If > we can swallow the Latin-1 stand-alone acute accent, we can swallow > anything. OK. But I hope in the future we will be able to correct obvious errors like the acute accent without objections of infidelity to the standard. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 12 10:15:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5O7q-0005E1-CM; Fri, 12 Jan 2007 10:15:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5O7o-0005Dp-U0 for ltru@ietf.org; Fri, 12 Jan 2007 10:15:24 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5O7n-0002er-Kd for ltru@ietf.org; Fri, 12 Jan 2007 10:15:24 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070112151519.BXJH20139.mta9.adelphia.net@DGBP7M81>; Fri, 12 Jan 2007 10:15:19 -0500 Message-ID: <008301c7365c$788b1360$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 12 Jan 2007 07:15:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Frank Ellermann Subject: [Ltru] Re: Last few questions for draft-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > +1 Google has about 1,140,000 hits for one L, and 280,000 for LL. MW > has Castlian and no Castillian. Maybe it's a typo in 639-3, they > should fix it. Until then use their spelling. I agree completely. If 639-3 fixes their spelling we can fix ours -- in fact, we've kind of obligated ourselves to do so. > Ugh. I hope that Galician wins. Until then "both" is fine. +1 >> For the macrolanguages Dogri, Konkani, Malay, and Swahili... > > +1 Can you live with it if we leave the qualifiers in, as John prefers? >> Should we maintain the relative order of existing Description fields >> and add new 639-3-based descriptions at the end, except that the >> reference name always becomes the first Description? (Default: Yes.) > > If you like it that way... what you get will be 639-3 reference > before 639-1/2 descriptions before other 639-3 descriptions (modulo > duplicates) Yes. What that would accomplish is to avoid reshuffling the existing order of names, except as necessary to keep the reference name first. The alternative, of course, is to put all the 639-3 names first, in order, followed by the 639-2 names. That reesulted in a LOT of swaps between, say, the third or fourth name, for no discernable reason. > I'd prefer a block of 639-3 descriptions automatically starting with > the reference name before anything else found in 639-1/2, but that's > mostly a matter of taste. Maybe my preference is better for > maintenance (?) Maybe it would be better. I'm open to suggestions, but I don't want to wait for months again. Suggestions on 4645bis have been in short supply so far. Does anyone object if I do this the way Frank prefers? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 12 10:40:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OWK-00055U-Dx; Fri, 12 Jan 2007 10:40:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OWH-0004u6-Q7 for ltru@ietf.org; Fri, 12 Jan 2007 10:40:41 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5OWG-0007sN-Ii for ltru@ietf.org; Fri, 12 Jan 2007 10:40:41 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H5OWG-0002LO-0V; Fri, 12 Jan 2007 10:40:40 -0500 Date: Fri, 12 Jan 2007 10:40:39 -0500 To: Doug Ewell Subject: Re: [Ltru] Re: Last few questions for draft-4645bis-01 Message-ID: <20070112154039.GB4484@ccil.org> References: <008301c7365c$788b1360$6601a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008301c7365c$788b1360$6601a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > >I'd prefer a block of 639-3 descriptions automatically starting with > >the reference name before anything else found in 639-1/2, but that's > >mostly a matter of taste. Maybe my preference is better for > >maintenance (?) > > Maybe it would be better. I'm open to suggestions, but I don't want to > wait for months again. Suggestions on 4645bis have been in short supply > so far. I think it would be better: -3 reference, then other -3, then -2/-1, and the more so because (with one or two exceptions) the -3 names are higher quality. -- Unless it was by accident that I had John Cowan offended someone, I never apologized. cowan@ccil.org --Quentin Crisp http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 12 11:36:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5POf-0003bW-7G; Fri, 12 Jan 2007 11:36:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5POc-0003ZZ-Pt for ltru@ietf.org; Fri, 12 Jan 2007 11:36:50 -0500 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5POb-0004v8-5q for ltru@ietf.org; Fri, 12 Jan 2007 11:36:50 -0500 Received: by an-out-0708.google.com with SMTP id d30so632240and for ; Fri, 12 Jan 2007 08:36:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=BNYcaPsGGaOk9jZFFYRDfl26ESZjXijFlbtPzj3iX6I5vDI0kYqeeZkyAglkfxU4ciTTo60TdOE24OX9JQw7Zw044EzA+g5twYdNqT7kfLxhXyR6+CJ1rUrGW0rswdwye9SKmjMq3SBSXjWA8p1Z178VOGK1+JyN9uZoWV1pVyE= Received: by 10.100.198.11 with SMTP id v11mr468159anf.1168619807803; Fri, 12 Jan 2007 08:36:47 -0800 (PST) Received: by 10.100.153.15 with HTTP; Fri, 12 Jan 2007 08:36:47 -0800 (PST) Message-ID: <30b660a20701120836k38671ba1oaf79011b35764041@mail.gmail.com> Date: Fri, 12 Jan 2007 08:36:47 -0800 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: Last few questions for draft-4645bis-01 In-Reply-To: <20070112154039.GB4484@ccil.org> MIME-Version: 1.0 References: <008301c7365c$788b1360$6601a8c0@DGBP7M81> <20070112154039.GB4484@ccil.org> X-Google-Sender-Auth: cd1bf7bbbed14f09 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Doug Ewell , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0659576334==" Errors-To: ltru-bounces@ietf.org --===============0659576334== Content-Type: multipart/alternative; boundary="----=_Part_5880_18941633.1168619807761" ------=_Part_5880_18941633.1168619807761 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree. For the other points Doug has, I agree with his suggestions. Mark On 1/12/07, John Cowan wrote: > > Doug Ewell scripsit: > > > >I'd prefer a block of 639-3 descriptions automatically starting with > > >the reference name before anything else found in 639-1/2, but that's > > >mostly a matter of taste. Maybe my preference is better for > > >maintenance (?) > > > > Maybe it would be better. I'm open to suggestions, but I don't want to > > wait for months again. Suggestions on 4645bis have been in short supply > > so far. > > I think it would be better: -3 reference, then other -3, then -2/-1, > and the more so because (with one or two exceptions) the -3 names are > higher quality. > > -- > Unless it was by accident that I had John Cowan > offended someone, I never apologized. cowan@ccil.org > --Quentin Crisp http://www.ccil.org/~cowan > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_5880_18941633.1168619807761 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree. For the other points Doug has, I agree with his suggestions.

Mark

On 1/12/07, John Cowan <cowan@ccil.org > wrote:
Doug Ewell scripsit:

> >I'd prefer a block of 639-3 descriptions automatically starting with
> >the reference name before anything else found in 639-1/2, but that's
> >mostly a matter of taste.  Maybe my preference is better for
> >maintenance (?)
>
> Maybe it would be better.  I'm open to suggestions, but I don't want to
> wait for months again.  Suggestions on 4645bis have been in short supply
> so far.

I think it would be better:  -3 reference, then other -3, then -2/-1,
and the more so because (with one or two exceptions) the -3 names are
higher quality.

--
Unless it was by accident that I had            John Cowan
offended someone, I never apologized.           cowan@ccil.org
        --Quentin Crisp                         http://www.ccil.org/~cowan

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



--
Mark ------=_Part_5880_18941633.1168619807761-- --===============0659576334== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0659576334==-- From ltru-bounces@ietf.org Fri Jan 12 12:44:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QSD-0007Cj-56; Fri, 12 Jan 2007 12:44:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QSB-0007A3-JM for ltru@lists.ietf.org; Fri, 12 Jan 2007 12:44:35 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5QSA-0005pL-AW for ltru@lists.ietf.org; Fri, 12 Jan 2007 12:44:35 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H5QS0-0002UE-Ff for ltru@lists.ietf.org; Fri, 12 Jan 2007 18:44:24 +0100 Received: from d252161.dialin.hansenet.de ([80.171.252.161]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Jan 2007 18:44:24 +0100 Received: from nobody by d252161.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Jan 2007 18:44:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 12 Jan 2007 18:42:45 +0100 Organization: Lines: 12 Message-ID: <45A7C895.4D5C@xyzzy.claranet.de> References: <008301c7365c$788b1360$6601a8c0@DGBP7M81> 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: d252161.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Last few questions for draft-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: >>> For the macrolanguages Dogri, Konkani, Malay, and Swahili... >> +1 > Can you live with it if we leave the qualifiers in, as John prefers? Yes. It's not nice, but the info is important. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 12 13:00:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QhK-0002nn-0h; Fri, 12 Jan 2007 13:00:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QhI-0002la-Hr for ltru@ietf.org; Fri, 12 Jan 2007 13:00:12 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5QhG-0000dM-9B for ltru@ietf.org; Fri, 12 Jan 2007 13:00:12 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H5QhF-0000DD-0M; Fri, 12 Jan 2007 13:00:09 -0500 Date: Fri, 12 Jan 2007 13:00:08 -0500 To: CE Whitehead Subject: Re: [Ltru] 639 coding wrt historic varieties (was RE: Request forvariant subtag Message-ID: <20070112180008.GD4484@ccil.org> References: <6d99d1fd0701111301x3b82bd38jc87ddfa532f1bca4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ietf-languages@iana.org, prosfilaes@gmail.com, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org CE Whitehead scripsit: > By the modern variety are you referring to the Latin that was used in the > Catholic service until recently and to the Latin used in various phrases > such as "e pluribus unum?" There's a lot more than that, from Newton's _Principia Mathematica_ to the weekly broadcast of world news in Latin from Finland. See http://en.wikipedia.org/wiki/Neo-Latin for details, but generally everything written after 1600 is considered Modern Latin. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The whole of Gaul is quartered into three halves. -- Julius Caesar _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 12 15:52:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5TNk-0004gs-JU; Fri, 12 Jan 2007 15:52:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5TNj-0004gm-BG for ltru@lists.ietf.org; Fri, 12 Jan 2007 15:52:11 -0500 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound3-sin-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5TNh-0005DD-6D for ltru@lists.ietf.org; Fri, 12 Jan 2007 15:52:11 -0500 Received: from outbound3-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-sin-R.bigfish.com (Postfix) with ESMTP id E2E368EBF7C; Fri, 12 Jan 2007 20:52:04 +0000 (UTC) Received: from mail87-sin-R.bigfish.com (unknown [10.3.252.3]) by outbound3-sin.bigfish.com (Postfix) with ESMTP id CE2F01BF0058; Fri, 12 Jan 2007 20:52:04 +0000 (UTC) Received: from mail87-sin (localhost.localdomain [127.0.0.1]) by mail87-sin-R.bigfish.com (Postfix) with ESMTP id A636921030E; Fri, 12 Jan 2007 20:52:04 +0000 (UTC) X-BigFish: VP Received: by mail87-sin (MessageSwitch) id 1168635124620690_6731; Fri, 12 Jan 2007 20:52:04 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail87-sin.bigfish.com (Postfix) with ESMTP id C2B0E2C004E; Fri, 12 Jan 2007 20:52:03 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007011211404486-2396240 ; Fri, 12 Jan 2007 11:40:44 -0800 In-Reply-To: <45A78944.6E26@xyzzy.claranet.de> To: Frank Ellermann Subject: Re: [Ltru] Re: Last few questions for draft-4645bis-01 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Fri, 12 Jan 2007 11:35:12 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 01/12/2007 11:35:13, Serialize complete at 01/12/2007 11:35:13, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/12/2007 11:40:44 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/12/2007 12:56:05 PM, Serialize complete at 01/12/2007 12:56:05 PM X-Spam-Score: 0.7 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0139777798==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0139777798== Content-Type: multipart/alternative; boundary="=_alternative 006BBACE88257261_=" This is a multipart message in MIME format. --=_alternative 006BBACE88257261_= Content-Type: text/plain; charset="US-ASCII" Frank Ellermann wrote on 01/12/2007 05:12:36 AM: > Doug Ewell wrote: > > > ISO 639-2 has "Castilian" with one L, while ISO 639-3 has "Castillian" > > with two L's. Use one or the other, or both? (Default: Holding my > > nose, I say "only the two-L version" purely because it is the 639-3 > > reference name. Personally I greatly prefer the one-L spelling, and > > hope the 639-2 and 639-3 people can get together and agree on a > > spelling.) > > +1 Google has about 1,140,000 hits for one L, and 280,000 for LL. > MW has Castlian and no Castillian. Maybe it's a typo in 639-3, > they should fix it. Until then use their spelling. This is definitely a spelling mistake and needs fixing, though I agree process-wise that ISO 639-3 needs to fix this and we should inherit the change once it's made. This error is pretty common as the term castellano in Spanish has two L's, but the English word does not. Who do we ping to get the ISO 639-3 data changed ASAP? This is not listed as an alternative spelling in any dictionary I have and I have a few. :) Regards, Karen Broome --=_alternative 006BBACE88257261_= Content-Type: text/html; charset="US-ASCII"
Frank Ellermann <nobody@xyzzy.claranet.de> wrote on 01/12/2007 05:12:36 AM:

> Doug Ewell wrote:
>
> > ISO 639-2 has "Castilian" with one L, while ISO 639-3 has "Castillian"
> > with two L's.  Use one or the other, or both?  (Default: Holding my
> > nose, I say "only the two-L version" purely because it is the 639-3
> > reference name.  Personally I greatly prefer the one-L spelling, and
> > hope the 639-2 and 639-3 people can get together and agree on a
> > spelling.)
>
> +1  Google has about 1,140,000 hits for one L, and 280,000 for LL.
>     MW has Castlian and no Castillian.  Maybe it's a typo in 639-3,
>     they should fix it.  Until then use their spelling.

This is definitely a spelling mistake and needs fixing, though I agree process-wise that ISO 639-3 needs to fix this and we should inherit the change once it's made. This error is pretty common as the term castellano in Spanish has two L's, but the English word does not.  

Who do we ping to get the ISO 639-3 data changed ASAP?

This is not listed as an alternative spelling in any dictionary I have and I have a few. :)

Regards,

Karen Broome --=_alternative 006BBACE88257261_=-- --===============0139777798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0139777798==-- From ltru-bounces@ietf.org Fri Jan 12 18:28:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Vp4-0005K9-C0; Fri, 12 Jan 2007 18:28:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QOw-00062W-2P for ltru@ietf.org; Fri, 12 Jan 2007 12:41:14 -0500 Received: from bay0-omc2-s4.bay0.hotmail.com ([65.54.246.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5QOt-0005Mc-M9 for ltru@ietf.org; Fri, 12 Jan 2007 12:41:14 -0500 Received: from hotmail.com ([65.54.169.28]) by bay0-omc2-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 12 Jan 2007 09:41:11 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 12 Jan 2007 09:41:10 -0800 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Fri, 12 Jan 2007 17:41:05 GMT X-Originating-IP: [209.133.185.129] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com In-Reply-To: <6d99d1fd0701111301x3b82bd38jc87ddfa532f1bca4@mail.gmail.com> From: "CE Whitehead" To: prosfilaes@gmail.com, mark.davis@icu-project.org Bcc: Subject: Re: [Ltru] 639 coding wrt historic varieties (was RE: Request forvariant subtag Date: Fri, 12 Jan 2007 12:41:05 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 12 Jan 2007 17:41:10.0997 (UTC) FILETIME=[D91A6050:01C73670] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Fri, 12 Jan 2007 18:28:33 -0500 Cc: ietf-languages@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Thanks for your comments on this issue: >There's several problems I see. The chronological lines between >languages are as arbitrary as any, and there is no way to predict when >the committee would draw the line between modern and pre-modern Czech. >So a user _cannot_ know whether cs applies to their 15th century Czech >books or not without bringing it up to the committee. +1 to this; this is the case with the French stuff too. In the late 16th century some of the texts are almost modern French (15th century French is clearly moyen francais); but even into the 17th century, when at the peripheries of French culture, some of the texts still are more like the earlier 16th century moyen francais texts. So while I support maybe having more macrolanguages incuding a macrolanguage for the various languages related to French, I do not think that the 16th-17th century issue can be resolved without a macrolanguage, by allowing the content writer to decide what tag is most appropriate for a given text, fr (French) or frm (moyne francais). >PS. I'll point out this has slightly absurd results when applied to >la. I think we can assume that la was designed to apply to Classical >Latin, and not (not just?) the modern variety. By the modern variety are you referring to the Latin that was used in the Catholic service until recently and to the Latin used in various phrases such as "e pluribus unum?" There's also the variety used by the Goliard poets, Medieval Latin. >Third, right now, the tagging for ancient languages is woefully >insufficient. Unless someone's willing to put a lot of work into >cataloging recorded ancient languages, a library like PG will end up >using the modern language tags for ancient languages instead of >fighting for dozens of new tags. To follow this path involves dozens >of new tags, which probably won't successfully be created piece-meal. I suspect that tagging is still worse for ancient varieties of non-Western non-Classical languages. I think we'll probably have to go about it all piecemeal though (on an as sought-for basis) and that way each case may get the attention it merits, as I think all these varieties merit special attention to prevent the tags from becoming just rigidly applied and ultra-systematic (for the sake of expediency) and perhaps not as meaningful and as useful as they should be. --C. E. Whitehead cewcathar@hotmail.com _________________________________________________________________ Your Hotmail address already works to sign into Windows Live Messenger! Get it now http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://get.live.com/messenger/overview _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 13 11:33:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5lou-0001mq-Mn; Sat, 13 Jan 2007 11:33:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5lot-0001mk-3e for ltru@lists.ietf.org; Sat, 13 Jan 2007 11:33:27 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5loq-0004i6-NX for ltru@lists.ietf.org; Sat, 13 Jan 2007 11:33:27 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H5log-0003hq-De for ltru@lists.ietf.org; Sat, 13 Jan 2007 17:33:14 +0100 Received: from du-001-234.access.de.clara.net ([212.82.227.234]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 13 Jan 2007 17:33:14 +0100 Received: from nobody by du-001-234.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 13 Jan 2007 17:33:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 13 Jan 2007 17:32:44 +0100 Organization: Lines: 15 Message-ID: <45A909AC.299A@xyzzy.claranet.de> References: <45A78944.6E26@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-234.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Ltru] Re: Last few questions for draft-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Karen_Broome@spe.sony.com wrote: > This error is pretty common as the term castellano in Spanish > has two L's, but the English word does not. BTW, the "Gallegan" might be similar, I found "Gallego" with Britannica, and the MW site told me that their info about "Gallegan" is only available for paying users. > Who do we ping to get the ISO 639-3 data changed ASAP? Whoever it is, I want the URL in 4646bis :-) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jan 13 12:02:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5mH6-0000EB-3z; Sat, 13 Jan 2007 12:02:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5mH5-0000E6-KF for ltru@lists.ietf.org; Sat, 13 Jan 2007 12:02:35 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5mH1-0001Z8-CT for ltru@lists.ietf.org; Sat, 13 Jan 2007 12:02:35 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H5mH0-00068f-IZ; Sat, 13 Jan 2007 12:02:30 -0500 Date: Sat, 13 Jan 2007 12:02:30 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: Last few questions for draft-4645bis-01 Message-ID: <20070113170230.GD8354@ccil.org> References: <45A78944.6E26@xyzzy.claranet.de> <45A909AC.299A@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45A909AC.299A@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > BTW, the "Gallegan" might be similar, I found "Gallego" with > Britannica, and the MW site told me that their info about > "Gallegan" is only available for paying users. The unabridged M-W tells us that "Gallegan" is a synonym for "Galician". > > Who do we ping to get the ISO 639-3 data changed ASAP? > > Whoever it is, I want the URL in 4646bis :-) mailto:iso639-3@sil.org , as a quick check of the 639-3 home page at http://www.sil.org/iso639-3 reveals. -- Yes, chili in the eye is bad, but so is your John Cowan ear. However, I would suggest you wash your cowan@ccil.org hands thoroughly before going to the toilet. http://www.ccil.org/~cowan --gadicath _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 14 21:40:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6HlJ-0000Xs-5r; Sun, 14 Jan 2007 21:39:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6HlF-0000SR-HJ for ltru@ietf.org; Sun, 14 Jan 2007 21:39:49 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Hjl-0006Fs-6E for ltru@ietf.org; Sun, 14 Jan 2007 21:38:20 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070115023811.ZFRR16871.mta10.adelphia.net@DGBP7M81> for ; Sun, 14 Jan 2007 21:38:11 -0500 Message-ID: <010801c7384e$32d14ad0$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 14 Jan 2007 18:38:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b0e0d49fdeccc4f4975ee60f85ef51 Subject: [Ltru] Submission: draft-ietf-ltru-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I've just submitted draft-ietf-ltru-4645bis-01 to Internet-Drafts@ietf.org. Because this draft is over 802,000 bytes and 916 pages long -- longer than the previous draft because of the inclusion of about 1,400 inverted/uninverted pairs -- I was once again disinclined to post it to the mailing list. Instead, I've attached a reduced version that includes all of the prose, but omits most of the proposed new Registry contents. You can view or download the complete draft at one of the following locations: http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.html (739,857 bytes) http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.html.zip (97,302 bytes) http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.txt (857,083 bytes) http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.txt.zip (101,713 bytes) Of course, once the draft is officially posted to the IETF site, you can get it there as well. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages -----8<-----cut here-----8<-----cut here-----8<-----cut here-----8<----- Network Working Group D. Ewell, Ed. Internet-Draft Consultant Intended status: Informational January 14, 2007 Expires: July 18, 2007 Update to the Language Subtag Registry draft-ietf-ltru-4645bis-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 July 18, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Ewell Expires July 18, 2007 [Page 1] Internet-Draft Update to the Language Subtag Registry January 2007 Abstract This memo defines the procedure used to update the IANA Language Subtag Registry in conjunction with the publication of RFC 4646bis [RFC EDITOR NOTE: replace with actual RFC number], for use in forming tags for the identification of languages. As an Internet-Draft, it also contained a complete replacement of the contents of the Registry to be used by IANA in updating it. To prevent confusion, this material was removed before publication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Updating the Registry . . . . . . . . . . . . . . . . . . . . 4 2.1. Starting Point . . . . . . . . . . . . . . . . . . . . . 4 2.2. New Subtags . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Modified Subtags . . . . . . . . . . . . . . . . . . . . 5 2.4. Grandfathered and Redundant Tags . . . . . . . . . . . . 6 2.5. Additional Changes . . . . . . . . . . . . . . . . . . . 9 3. Updated Registry Contents . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 909 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 910 6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 911 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 912 7.1. Normative References . . . . . . . . . . . . . . . . . . 912 7.2. Informative References . . . . . . . . . . . . . . . . . 912 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 914 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 915 Intellectual Property and Copyright Statements . . . . . . . . . 916 Ewell Expires July 18, 2007 [Page 2] Internet-Draft Update to the Language Subtag Registry January 2007 1. Introduction [RFC4646] provided for a Language Subtag Registry and described its format. The initial contents of the Registry and rules for determining them were specified in [RFC4645]. [draft-ietf-ltru-4646bis-02] expands on [RFC4646] by adding support for approximately 7,200 primary and extended language subtags based on [ISO639-3] alpha-3 code elements. This memo describes the process of updating the Registry to include these additional subtags, and to make secondary changes to the Registry that result from adding the new subtags. In its initial phase as an Internet-Draft, this memo also contained a complete replacement of the contents of the Language Subtag Registry to be used by the Internet Assigned Numbers Authority (IANA) in updating it. This content was deleted from this memo prior to publication as an RFC. The format of the Language Subtag Registry, and the definition and intended purpose of each of the fields, are described in [draft-ietf-ltru-4646bis-02]. 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 [draft-ietf-ltru-4646bis-02]. In its Internet-Draft phase, this memo did not define the permanent contents of the Registry and should not be represented as doing so. Many of the subtags defined in the Language Subtag Registry are based on code elements defined in [ISO639-1], [ISO639-2], [ISO639-3], [ISO3166-1], [ISO15924], and [UN_M.49]. The Registry is not a mirror of the code lists defined by these standards and should not be used as one. Ewell Expires July 18, 2007 [Page 3] Internet-Draft Update to the Language Subtag Registry January 2007 2. Updating the Registry This section describes the process for determining the updated contents of the Language Subtag Registry. 2.1. Starting Point The version of the Language Subtag Registry that was current at the time of IESG approval of this memo served as the starting point for this update. The process of creating that version was described in [RFC4645]. The source data for [ISO639-3] used for this update consisted of three files, available from the official site of the ISO 639-3 Registration Authority. [RFC EDITOR NOTE: these files are expected to be updated before approval of this memo.] o [iso-fdis-639-3_20061114] is a list of all language code elements in [ISO639-3], including the alpha-3 code element and reference name for each code element. For example, the entry for the Dari language contained the code element "prs" and the name "Dari" (among other information). o [iso-fdis-639-3_Name_Index_20061114] is a list containing all names associated with each language according to [ISO639-3], including both inverted and uninverted forms where appropriate. A code element may have more than one entry in this file; the reference name and its inverted form are usually, but not always, given in the first entry. For example, this file contained an entry for the code element "prs" with the name "Dari" (twice) and another entry with the names "Eastern Farsi" and "Farsi, Eastern". o [iso-fdis-639-3-macrolanguages_20061114] is a list of all alpha-3 code elements for languages that are encompassed by a macrolanguage in [ISO639-3], together with the alpha-3 code element for the macrolanguage. For example, a line containing the code elements "fas" and "prs" indicated that the macrolanguage "Persian" encompasses the individual language "Dari". (Note that these alpha-3 code elements may not have corresponded directly to subtags in the Registry, which uses 2-letter subtags derived from [ISO639-1] when possible.) The value of the File-Date field and of the Added date for each new subtag record are set to a date near the date of IESG approval of this memo. [RFC EDITOR NOTE: these dates would be updated during AUTH48.] Ewell Expires July 18, 2007 [Page 4] Internet-Draft Update to the Language Subtag Registry January 2007 2.2. New Subtags For each language in [ISO639-3] that was not already represented by a primary language subtag in the Language Subtag Registry, a new subtag was added to the Registry, using the [ISO639-3] code element as the value for the Subtag field and each of the [ISO639-3] names as a separate Description field. The [ISO639-3] reference name was represented by the first Description field. The following rules were used to determine whether to add a primary or extended language subtag: o If the language was encompassed by a macrolanguage, as determined by [iso-fdis-639-3-macrolanguages_20061114], an extended language subtag was added, with the primary language subtag of the macrolanguage as the value for the Prefix field. o If the name of the language included the words "Sign Language", an extended language subtag was added, with the string "sgn" as the value for the Prefix field. This is a special case that treats the existing primary language subtag for "Sign Languages" as if it were a macrolanguage encompassing all sign languages. (Note that "sgn" is defined as a "collection code" by [ISO639-3] and hence is not included in that standard.) o Otherwise, a primary language subtag was added. All subtags were added to the Registry maintaining alphabetical order within each type of tag: all 2-letter "language" subtags first, then all 3-letter "language" subtags, and finally all all "extlang" subtags. Some existing records were moved to ensure this order. 2.3. Modified Subtags For each language in [ISO639-3] that was already represented by a primary language subtag in the Language Subtag Registry, Description fields were added as necessary to reflect all names listed for that language (inverted and uninverted) in either [iso-fdis-639-3_20061114] or [iso-fdis-639-3_Name_Index_20061114]. The order of Description fields was adjusted to ensure that the reference name from [ISO639-3] was listed first, followed by other names from [ISO639-3] in the order presented by that standard, followed by any other names already existing in the Registry. In some cases this resulted in a reordering of Description fields for existing entries, even when no new values were added. No existing Description fields were changed or deleted, with the following exceptions: Ewell Expires July 18, 2007 [Page 5] Internet-Draft Update to the Language Subtag Registry January 2007 o For the primary language subtag "es", the Description "Castilian" was replaced by the [ISO639-3] spelling "Castillian". This was presumed to be an unintentional and temporary mismatch between [ISO639-2] and [ISO639-3]. o For similar reasons, the following spelling changes were made to existing Description fields in the Registry to bring them in line with the corresponding names in [ISO639-3]: "gsw" changed from "Alemannic" to "Alemanic" "gwi" changed from "Gwich´in" to "Gwich'in" "nqo" changed from "N’Ko" to "N'Ko" "rup" changed from "Macedo-Romanian" to "Macedo Romanian" o The capitalization of the Subtag field for the redundant tag "yi- latn" was changed to "yi-Latn" for consistency with the capitalization conventions described in Section 2.1 of [draft-ietf-ltru-4646bis-02]. 2.4. Grandfathered and Redundant Tags As stated in [draft-ietf-ltru-4646bis-02], "grandfathered" and "redundant" tags are complete tags in the Language Subtag Registry that were registered under [RFC1766] or [RFC3066] and remain valid. Grandfathered tags cannot be generated from a valid combination of subtags, while "redundant" tags can be. Under certain conditions, registration of a subtag under [draft-ietf-ltru-4646bis-02] may cause a grandfathered tag to be reclassified as redundant. It may also enable the creation of a generative tag with the same meaning as a grandfathered or redundant tag; in that case, the grandfathered or redundant tag is marked as Deprecated, and the generative tag (including the new subtag) becomes its Preferred-Value. As a result of adding the new subtags in this update, the following grandfathered tags became composable and were reclassified as redundant: zh-cmn zh-cmn-Hans zh-cmn-Hant Ewell Expires July 18, 2007 [Page 6] Internet-Draft Update to the Language Subtag Registry January 2007 zh-gan zh-wuu zh-yue The following grandfathered tags were deprecated, with the indicated generative tag serving as the Preferred-Value: i-ami (Preferred-Value: ami) i-bnn (Preferred-Value: bnn) i-pwn (Preferred-Value: pwn) i-tao (Preferred-Value: tao) i-tay (Preferred-Value: tay) i-tsu (Preferred-Value: tsu) sgn-CH-de (Preferred-Value: sgn-sgg) zh-hakka (Preferred-Value: zh-hak) zh-min (no Preferred-Value; see below) zh-min-nan (Preferred-Value: zh-nan) zh-xiang (Preferred-Value: zh-hns) The tag "zh-min", originally registered under [RFC1766], is a special case: it represents a small class of languages, but is not a true macrolanguage. It could not ever become a generative tag since the [ISO639-3] code element "min" is assigned to an individual language (Minangkabau) that is not related to Chinese ("zh"). Because it is not believed to represent a useful linguistic entity for tagging purposes, it was deprecated without a Preferred-Value. The following redundant sign-language tags were deprecated, with the indicated generative tag serving as the Preferred-Value: sgn-BR (Preferred-Value: sgn-bzs) sgn-CO (Preferred-Value: sgn-csn) sgn-DE (Preferred-Value: sgn-gsg) Ewell Expires July 18, 2007 [Page 7] Internet-Draft Update to the Language Subtag Registry January 2007 sgn-DK (Preferred-Value: sgn-dsl) sgn-ES (Preferred-Value: sgn-ssp) sgn-FR (Preferred-Value: sgn-fsl) sgn-GB (Preferred-Value: sgn-bfi) sgn-GR (Preferred-Value: sgn-gss) sgn-IE (Preferred-Value: sgn-isg) sgn-IT (Preferred-Value: sgn-ise) sgn-JP (Preferred-Value: sgn-jsl) sgn-MX (Preferred-Value: sgn-mfs) sgn-NI (Preferred-Value: sgn-ncs) sgn-NL (Preferred-Value: sgn-dse) sgn-NO (Preferred-Value: sgn-nsl) sgn-PT (Preferred-Value: sgn-psr) sgn-SE (Preferred-Value: sgn-swl) sgn-US (Preferred-Value: sgn-ase) sgn-ZA (Preferred-Value: sgn-sfs) No change was made to the Description field(s) for any of the grandfathered or redundant tags. For example, the redundant tag "sgn-US" continues to carry the Description "American Sign Language". The sign language tags registered prior to [RFC4646] remain an exception to the general principle that the meaning of a non- grandfathered tag can be derived from its component subtags. In previous versions of the Registry, grandfathered tags that had been deprecated as a result of adding an ISO 639-based language subtag included a Comments field, with a value of the form "replaced by ISO code xxx", where "xxx" represented the new language subtag. These comments duplicated the information contained within the Preferred-Value field, and were deleted as part of this update. No changes were made to other Comments fields. Ewell Expires July 18, 2007 [Page 8] Internet-Draft Update to the Language Subtag Registry January 2007 2.5. Additional Changes For consistency with the handling of alternative names in language subtags, Description fields for script subtags taken from [ISO15924] that represent alternative names were converted to multiple Description fields. For example, the Description "Han (Hanzi, Kanji, Hanja)" was converted to four separate Description fields. Some Description fields for script subtags contained parenthetical material that was explanatory, rather than identifying alternative names; these fields were not altered. The situation does not apply to region subtags taken from [ISO3166-1] and [UN_M.49] because those standards do not provide freely available alternative names for code elements. Ewell Expires July 18, 2007 [Page 9] Internet-Draft Update to the Language Subtag Registry January 2007 3. Updated Registry Contents The remainder of this section specified the updated set of records for the Language Subtag Registry. This material was deleted before publication of this memo, to avoid any potential confusion with the Registry itself. The IANA Language Subtag Registry can be found at under "Language Tags". [RFC EDITOR NOTE: the remainder of this section is to be deleted upon publication.] The updated contents of the Language Subtag Registry follow. This data is intended as a complete replacement for the current contents of the Registry. 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: 2008-01-01 %% Type: language Subtag: aa Description: Afar Added: 2005-10-16 %% Type: language Subtag: ab Description: Abkhazian Added: 2005-10-16 Suppress-Script: Cyrl %% Type: language Subtag: ae Description: Avestan Added: 2005-10-16 %% Type: language Subtag: af Description: Afrikaans Added: 2005-10-16 Suppress-Script: Latn %% Type: language Subtag: ak Description: Akan Added: 2005-10-16 Ewell Expires July 18, 2007 [Page 10] Internet-Draft Update to the Language Subtag Registry January 2007 Description: Cantonese Added: 1999-12-18 Ewell Expires July 18, 2007 [Page 908] Internet-Draft Update to the Language Subtag Registry January 2007 4. Security Considerations For security considerations relevant to the Language Subtag Registry and the use of language tags, see [draft-ietf-ltru-4646bis-02]. Ewell Expires July 18, 2007 [Page 909] Internet-Draft Update to the Language Subtag Registry January 2007 5. IANA Considerations In its initial phase as an Internet-Draft, this memo contained a complete replacement of the contents of the Language Subtag Registry to be used by IANA in updating it. As an RFC, it contains a pointer to the Registry, which is maintained by IANA. The Language Subtag Registry can be found at under "Language Tags". For details on the procedures for the format and ongoing maintenance of this Registry, see [draft-ietf-ltru-4646bis-02]. Ewell Expires July 18, 2007 [Page 910] Internet-Draft Update to the Language Subtag Registry January 2007 6. Changes [Editor's Note: This section is provided for the convenience of reviewers and will be removed from the final document.] This memo is a new work, not an incremental update. The procedure for populating the original Language Subtag Registry, specified by the earlier [RFC4646], is included by reference to [RFC4645]. Therefore, no changes from [RFC4645] are listed in this section. Changes between draft-ietf-ltru-4645bis-00 and this version are: o Changed procedure to incorporate data from new "Language Names Index" file and to ensure that the [ISO639-3] reference name is the first Description field. o Removed some exceptions as a result of improved [ISO639-3] draft data. o Removed section dealing with special handling of "(generic)" and "(specific)" strings within language names. o Added an explanation of the process of converting a compound Description field for a script subtag to multiple Description fields. o Removed Comments fields of the form "replaced by ISO code xxx", which provided no additional information beyond the Preferred- Value field. o Clarified that the included Registry contents are a complete replacement for the existing Registry, not a set of deltas. (J. Cowan) o Changed "included within" a macrolanguage to use "encompassed by" throughout. (J. Cowan) o Provided better explanation for deprecation of "zh-min" in Section 2.4. (J. Cowan) o Added Changes and Acknowledgements sections. Ewell Expires July 18, 2007 [Page 911] Internet-Draft Update to the Language Subtag Registry January 2007 7. References 7.1. Normative References [ISO639-3] International Organization for Standardization, "ISO/FDIS 639-3:2007. Codes for the representation of names of languages -- Part 3: Alpha-3 code for comprehensive coverage of languages, first edition", 2007. [draft-ietf-ltru-4646bis-02] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", December 2006, . [iso-fdis-639-3-macrolanguages_20061114] International Organization for Standardization, "ISO/FDIS 639-3 Macrolanguage Mappings", November 2006, . [iso-fdis-639-3_20061114] International Organization for Standardization, "ISO/FDIS 639-3 Code Set", November 2006, . [iso-fdis-639-3_Name_Index_20061114] International Organization for Standardization, "ISO/FDIS 639-3 Language Names Index", November 2006, . 7.2. Informative References [ISO15924] International Organization for Standardization, "ISO 15924:2004. Information and documentation -- Codes for the representation of names of scripts", January 2004. [ISO3166-1] International Organization for Standardization, "ISO 3166: 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. Ewell Expires July 18, 2007 [Page 912] Internet-Draft Update to the Language Subtag Registry January 2007 [ISO639-2] International Organization for Standardization, "ISO 639- 2:1998. Codes for the representation of names of languages -- Part 2: Alpha-3 code, first edition", 1998. [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", RFC 3066, January 2001. [RFC4645] Ewell, D., "Initial Language Subtag Registry", RFC 4645, September 2006. [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006. [UN_M.49] Statistics Division, United Nations, "Standard Country or Area Codes for Statistical Use", UN Standard Country or Area Codes for Statistical Use, Revision 4 (United Nations publication, Sales No. 98.XVII.9), June 1999. Ewell Expires July 18, 2007 [Page 913] Internet-Draft Update to the Language Subtag Registry January 2007 Appendix A. Acknowledgements This memo is a collaborative work of the Language Tag Registry Update (LTRU) Working Group. All of its members have made significant contributions to this memo and to its predecessor, [RFC4645]. Specific contributions to this memo were made by John Cowan, Mark Davis, Martin Duerst, Frank Ellermann, Kent Karlsson, and Addison Phillips. This document was written with the xml2rfc tool described in [RFC2629]. Ewell Expires July 18, 2007 [Page 914] Internet-Draft Update to the Language Subtag Registry January 2007 Author's Address Doug Ewell (editor) Consultant Email: dewell@adelphia.net URI: http://users.adelphia.net/~dewell Ewell Expires July 18, 2007 [Page 915] Internet-Draft Update to the Language Subtag Registry January 2007 Full Copyright Statement Copyright (C) The Internet Society (2007). 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Ewell Expires July 18, 2007 [Page 916] _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 14 22:02:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6I6s-0004vQ-MH; Sun, 14 Jan 2007 22:02:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6I6r-0004v3-4r for ltru@ietf.org; Sun, 14 Jan 2007 22:02:09 -0500 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6I6p-0000SQ-QH for ltru@ietf.org; Sun, 14 Jan 2007 22:02:09 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070115030203.BRLA2904.mta13.adelphia.net@DGBP7M81> for ; Sun, 14 Jan 2007 22:02:03 -0500 Message-ID: <011001c73851$881ac270$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 14 Jan 2007 19:02:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I ran draft-4645bis-01 through idnits and it gave me the following: Checking conformance with RFC 3978/3979 boilerplate... - This document has ISOC Copyright according to RFC 3978, instead of the newer IETF Trust Copyright according to RFC 4748. You should consider updating it; the new Copyright statement will be required from February 1st, 2007 - This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. You should consider updating it; the new disclaimer will be required from February 1st, 2007 I used the online version of xml2rfc 1.31 to generate all the boilerplate. Does anyone know if the newer, "living on the edge" version applies the updated boilerplate? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 14 23:49:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Jmn-0003N9-8A; Sun, 14 Jan 2007 23:49:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Jml-0003N4-KN for ltru@lists.ietf.org; Sun, 14 Jan 2007 23:49:31 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Jmk-0008AT-Bo for ltru@lists.ietf.org; Sun, 14 Jan 2007 23:49:31 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H6Jma-00066J-Tm for ltru@lists.ietf.org; Mon, 15 Jan 2007 05:49:20 +0100 Received: from 212.82.251.27 ([212.82.251.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Jan 2007 05:49:20 +0100 Received: from nobody by 212.82.251.27 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Jan 2007 05:49:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 15 Jan 2007 05:39:10 +0100 Organization: Lines: 11 Message-ID: <45AB056E.27F@xyzzy.claranet.de> References: <011001c73851$881ac270$6601a8c0@DGBP7M81> 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.27 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Does anyone know if the newer, "living on the edge" > version applies the updated boilerplate? It does, since November (version 1.32pre2). You can ignore this nit for the time being Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 15 23:15:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6fiz-0005Ng-Qk; Mon, 15 Jan 2007 23:15:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6fiy-0005NW-LF for ltru@ietf.org; Mon, 15 Jan 2007 23:15:04 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6fic-0004jt-Ob for ltru@ietf.org; Mon, 15 Jan 2007 23:14:44 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070116041437.YIHP20139.mta9.adelphia.net@DGBP7M81> for ; Mon, 15 Jan 2007 23:14:37 -0500 Message-ID: <000e01c73924$d61f7460$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 15 Jan 2007 20:14:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Yes, I see the "all all" in the last paragraph of Section 2.2. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 16 14:59:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6uSg-0000aH-Ms; Tue, 16 Jan 2007 14:59:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6uSf-0000Zg-ON for ltru@lists.ietf.org; Tue, 16 Jan 2007 14:59:13 -0500 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound4-sin-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6uSa-0004gw-MP for ltru@lists.ietf.org; Tue, 16 Jan 2007 14:59:13 -0500 Received: from outbound4-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound4-sin-R.bigfish.com (Postfix) with ESMTP id ACEBB90078B; Tue, 16 Jan 2007 19:59:06 +0000 (UTC) Received: from mail20-sin-R.bigfish.com (unknown [10.3.252.3]) by outbound4-sin.bigfish.com (Postfix) with ESMTP id 9D55428005E; Tue, 16 Jan 2007 19:59:06 +0000 (UTC) Received: from mail20-sin (localhost.localdomain [127.0.0.1]) by mail20-sin-R.bigfish.com (Postfix) with ESMTP id 747ABF180A3; Tue, 16 Jan 2007 19:59:06 +0000 (UTC) X-BigFish: VP Received: by mail20-sin (MessageSwitch) id 1168977546456923_2206; Tue, 16 Jan 2007 19:59:06 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail20-sin.bigfish.com (Postfix) with ESMTP id 0B2A51B70089; Tue, 16 Jan 2007 19:59:06 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007011611003177-2475392 ; Tue, 16 Jan 2007 11:00:31 -0800 To: iso639-3@sil.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Tue, 16 Jan 2007 10:54:56 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 01/16/2007 10:54:57, Serialize complete at 01/16/2007 10:54:57, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/16/2007 11:00:31 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/16/2007 12:03:10 PM, Serialize complete at 01/16/2007 12:03:10 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ltru@lists.ietf.org Subject: [Ltru] Question about 639-3 value "Castillian" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============2134798477==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============2134798477== Content-Type: multipart/alternative; boundary="=_alternative 00680B5688257265_=" This is a multipart message in MIME format. --=_alternative 00680B5688257265_= Content-Type: text/plain; charset="US-ASCII" To Whom It May Concern, I have a question about the reference name used in ISO 639-3 for the code "spa." The name is now listed as "Castillian" and I believe this to be a misspelling. The correct spelling in English is "Castilian" as found in ISO 639-2 and on the Ethnologue site. The Spanish and French spellings -- castellano and castillan -- use two L's, but I believe the term should be spelled with one L in English. Reference URL: http://www.sil.org/iso639%2D3/documentation.asp?id=spa Should this name be updated? Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 --=_alternative 00680B5688257265_= Content-Type: text/html; charset="US-ASCII"
To Whom It May Concern,

I have a question about the reference name used in ISO 639-3 for the code "spa."

The name is now listed as "Castillian" and I believe this to be a misspelling. The correct spelling in English is "Castilian" as found in ISO 639-2 and on the Ethnologue site. The Spanish and French spellings -- castellano and castillan -- use two L's, but I believe the term should be spelled with one L in English.

        Reference URL:
       http://www.sil.org/iso639%2D3/documentation.asp?id=spa

Should this name be updated?

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384 --=_alternative 00680B5688257265_=-- --===============2134798477== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2134798477==-- From ltru-bounces@ietf.org Tue Jan 16 16:12:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vbz-0003R1-VM; Tue, 16 Jan 2007 16:12:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vbx-0003Pm-O2 for ltru@lists.ietf.org; Tue, 16 Jan 2007 16:12:53 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6vbu-0007TA-4S for ltru@lists.ietf.org; Tue, 16 Jan 2007 16:12:53 -0500 Received: from MikeLaptop ([82.69.111.196]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 16 Jan 2007 21:12:45 +0000 From: "Chris Cox" To: , References: Subject: RE: [Ltru] Question about 639-3 value "Castillian" Date: Tue, 16 Jan 2007 21:12:46 -0000 Message-ID: <000901c739b3$120f72c0$6400a8c0@MikeLaptop> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc5qUVn1ZIDdKe+RK+6ScEIAeyxxAAB1/Ug X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1954646237==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1954646237== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C739B3.120F72C0" This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C739B3.120F72C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Karen, I am not sure of the process for dealing with spelling mistakes in the 639-6 database, especially since it has not yet been published but is in final stages as described by Peter the other day but I think it is pretty certain that the English spelling is with one L (I checked with a visit to "One Look Dictionary" where the 13 listed dictionaries gave that spelling, whereas an entry with two LLs gave only one hit and that was the Wikipedia disambiguation page for the name spelt with one L). Regards Chris _____ From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] Sent: 16 January 2007 18:55 To: iso639-3@sil.org Cc: ltru@lists.ietf.org Subject: [Ltru] Question about 639-3 value "Castillian" To Whom It May Concern, I have a question about the reference name used in ISO 639-3 for the code "spa." The name is now listed as "Castillian" and I believe this to be a misspelling. The correct spelling in English is "Castilian" as found in ISO 639-2 and on the Ethnologue site. The Spanish and French spellings -- castellano and castillan -- use two L's, but I believe the term should be spelled with one L in English. Reference URL: http://www.sil.org/iso639%2D3/documentation.asp?id=spa Should this name be updated? Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 ------=_NextPart_000_000A_01C739B3.120F72C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Karen,

I am not sure of the process for = dealing with spelling mistakes in the 639-6 database, especially since it has = not yet been published but is in final stages as described by Peter the other = day but I think it is pretty certain that the English spelling is with one L (I = checked with a visit to “One Look Dictionary” where the 13 listed = dictionaries gave that spelling, whereas an entry with two LLs gave only one hit and = that was the Wikipedia disambiguation page for the name spelt with one L). =  

Regards

=

Chris

 

From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com]
Sent: 16 January 2007 = 18:55
To: iso639-3@sil.org
Cc: = ltru@lists.ietf.org
Subject: [Ltru] Question = about 639-3 value "Castillian"

 


To Whom It May Concern,

I have a question about the reference name used in ISO 639-3 for the code "spa."

The name is now listed as "Castillian" and I believe this to be a misspelling. The correct spelling in English is "Castilian" as = found in ISO 639-2 and on the Ethnologue site. The Spanish and French = spellings -- castellano and castillan -- use two L's, but I believe the term should = be spelled with one L in English.

        Reference URL:
      =  http://www.sil.org/iso639%2D3/documentation.asp?id=3Dspa

Should this name be updated?

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384

------=_NextPart_000_000A_01C739B3.120F72C0-- --===============1954646237== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1954646237==-- From ltru-bounces@ietf.org Tue Jan 16 17:27:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wlr-00085L-Py; Tue, 16 Jan 2007 17:27:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wlr-00082U-76 for ltru@lists.ietf.org; Tue, 16 Jan 2007 17:27:11 -0500 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound3-dub-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wlo-0003b3-Am for ltru@lists.ietf.org; Tue, 16 Jan 2007 17:27:11 -0500 Received: from outbound3-dub.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-dub-R.bigfish.com (Postfix) with ESMTP id BDBCD142B9ED; Tue, 16 Jan 2007 22:27:05 +0000 (UTC) Received: from mail41-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound3-dub.bigfish.com (Postfix) with ESMTP id 9D8341F804D; Tue, 16 Jan 2007 22:27:05 +0000 (UTC) Received: from mail41-dub (localhost.localdomain [127.0.0.1]) by mail41-dub-R.bigfish.com (Postfix) with ESMTP id 73F2A14E00EF; Tue, 16 Jan 2007 22:27:05 +0000 (UTC) X-BigFish: VP Received: by mail41-dub (MessageSwitch) id 1168986424751935_31588; Tue, 16 Jan 2007 22:27:04 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail41-dub.bigfish.com (Postfix) with ESMTP id 020DCCC006C; Tue, 16 Jan 2007 22:27:03 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007011614310410-2486559 ; Tue, 16 Jan 2007 14:31:04 -0800 In-Reply-To: <000901c739b3$120f72c0$6400a8c0@MikeLaptop> To: "Chris Cox" Subject: RE: [Ltru] Question about 639-3 value "Castillian" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Tue, 16 Jan 2007 14:25:28 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 01/16/2007 14:25:28, Serialize complete at 01/16/2007 14:25:28, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/16/2007 02:31:04 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 01/16/2007 02:31:08 PM, Serialize complete at 01/16/2007 02:31:08 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1591938176==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1591938176== Content-Type: multipart/alternative; boundary="=_alternative 007B51EF88257265_=" This is a multipart message in MIME format. --=_alternative 007B51EF88257265_= Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="UTF-8" U29ycnksIENocmlzLiBJIHNob3VsZCBoYXZlIG1hZGUgaXQgY2xlYXIgdGhhdCB0aGlzIHdhcyBh IGZvcm1hbCByZXF1ZXN0IA0KdG8gSVNPIDYzOS0zIHRvIGNoYW5nZSB0aGlzIHNwZWxsaW5nLiBJ IGNjJ2VkIHRoZSBMVFJVIGxpc3QgZm9yIA0KaW5mb3JtYXRpb24gb25seS4gDQoNCkkgd2Fzbid0 IGFkZHJlc3NpbmcgYW55IGNvbmNlcm5zIHdpdGggSVNPIDYzOS02IGluIHRoZSBlLW1haWwgYmVs b3csIEkgDQpqdXN0IHdhbnRlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgZm9sa3MgaW4gTFRSVSBr bmV3IEkgaGFkIGFscmVhZHkgDQpzdWJtaXR0ZWQgdGhpcyBjaGFuZ2UgcmVxdWVzdCBhcyBwZXIg YW4gZWFybGllciB0aHJlYWQuIEV0aG5vbG9ndWUgc2VlbXMgDQp0byBoYXZlIHRoaXMgcmlnaHQg c28gSSdtIG5vdCBzdXJlIHlvdSBoYXZlIGEgcHJvYmxlbSB3aXRoIDYzOS02LiBJJ3ZlIA0Kb25s eSBzZWVuIHRoaXMgaW4gNjM5LTMuDQoNClJlZ2FyZHMsDQoNCkthcmVuIEJyb29tZQ0KDQoNCg0K DQoNCiJDaHJpcyBDb3giIDxjaHJpcy5jb3hAZ2VvbGFuZy5jb20+IA0KMDEvMTYvMjAwNyAwMTox MiBQTQ0KDQpUbw0KPEthcmVuX0Jyb29tZUBzcGUuc29ueS5jb20+LCA8aXNvNjM5LTNAc2lsLm9y Zz4NCmNjDQpsdHJ1QGxpc3RzLmlldGYub3JnDQpTdWJqZWN0DQpSRTogW0x0cnVdIFF1ZXN0aW9u IGFib3V0IDYzOS0zIHZhbHVlICJDYXN0aWxsaWFuIg0KDQoNCg0KDQoNCg0KS2FyZW4sDQpJIGFt IG5vdCBzdXJlIG9mIHRoZSBwcm9jZXNzIGZvciBkZWFsaW5nIHdpdGggc3BlbGxpbmcgbWlzdGFr ZXMgaW4gdGhlIA0KNjM5LTYgZGF0YWJhc2UsIGVzcGVjaWFsbHkgc2luY2UgaXQgaGFzIG5vdCB5 ZXQgYmVlbiBwdWJsaXNoZWQgYnV0IGlzIGluIA0KZmluYWwgc3RhZ2VzIGFzIGRlc2NyaWJlZCBi eSBQZXRlciB0aGUgb3RoZXIgZGF5IGJ1dCBJIHRoaW5rIGl0IGlzIHByZXR0eSANCmNlcnRhaW4g dGhhdCB0aGUgRW5nbGlzaCBzcGVsbGluZyBpcyB3aXRoIG9uZSBMIChJIGNoZWNrZWQgd2l0aCBh IHZpc2l0IHRvIA0K4oCcT25lIExvb2sgRGljdGlvbmFyeeKAnSB3aGVyZSB0aGUgMTMgbGlzdGVk IGRpY3Rpb25hcmllcyBnYXZlIHRoYXQgc3BlbGxpbmcsIA0Kd2hlcmVhcyBhbiBlbnRyeSB3aXRo IHR3byBMTHMgZ2F2ZSBvbmx5IG9uZSBoaXQgYW5kIHRoYXQgd2FzIHRoZSBXaWtpcGVkaWEgDQpk aXNhbWJpZ3VhdGlvbiBwYWdlIGZvciB0aGUgbmFtZSBzcGVsdCB3aXRoIG9uZSBMKS4gDQpSZWdh cmRzDQpDaHJpcw0KIA0KDQpGcm9tOiBLYXJlbl9Ccm9vbWVAc3BlLnNvbnkuY29tIFttYWlsdG86 S2FyZW5fQnJvb21lQHNwZS5zb255LmNvbV0gDQpTZW50OiAxNiBKYW51YXJ5IDIwMDcgMTg6NTUN ClRvOiBpc282MzktM0BzaWwub3JnDQpDYzogbHRydUBsaXN0cy5pZXRmLm9yZw0KU3ViamVjdDog W0x0cnVdIFF1ZXN0aW9uIGFib3V0IDYzOS0zIHZhbHVlICJDYXN0aWxsaWFuIg0KIA0KDQpUbyBX aG9tIEl0IE1heSBDb25jZXJuLCANCg0KSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgdGhlIHJlZmVy ZW5jZSBuYW1lIHVzZWQgaW4gSVNPIDYzOS0zIGZvciB0aGUgY29kZSANCiJzcGEuIiANCg0KVGhl IG5hbWUgaXMgbm93IGxpc3RlZCBhcyAiQ2FzdGlsbGlhbiIgYW5kIEkgYmVsaWV2ZSB0aGlzIHRv IGJlIGEgDQptaXNzcGVsbGluZy4gVGhlIGNvcnJlY3Qgc3BlbGxpbmcgaW4gRW5nbGlzaCBpcyAi Q2FzdGlsaWFuIiBhcyBmb3VuZCBpbiANCklTTyA2MzktMiBhbmQgb24gdGhlIEV0aG5vbG9ndWUg c2l0ZS4gVGhlIFNwYW5pc2ggYW5kIEZyZW5jaCBzcGVsbGluZ3MgLS0gDQpjYXN0ZWxsYW5vIGFu ZCBjYXN0aWxsYW4gLS0gdXNlIHR3byBMJ3MsIGJ1dCBJIGJlbGlldmUgdGhlIHRlcm0gc2hvdWxk IGJlIA0Kc3BlbGxlZCB3aXRoIG9uZSBMIGluIEVuZ2xpc2guIA0KDQogICAgICAgIFJlZmVyZW5j ZSBVUkw6IA0KICAgICAgIGh0dHA6Ly93d3cuc2lsLm9yZy9pc282MzklMkQzL2RvY3VtZW50YXRp b24uYXNwP2lkPXNwYSANCg0KU2hvdWxkIHRoaXMgbmFtZSBiZSB1cGRhdGVkPyANCg0KUmVnYXJk cywgDQoNCkthcmVuIEJyb29tZQ0KTWV0YWRhdGEgU3lzdGVtcyBEZXNpZ25lcg0KU29ueSBQaWN0 dXJlcyBFbnRlcnRhaW5tZW50DQozMTAuMjQ0LjQzODRfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KTHRydSBtYWlsaW5nIGxpc3QNCkx0cnVAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg0KDQo= --=_alternative 007B51EF88257265_= Content-Transfer-Encoding: base64 Content-Type: text/html; charset="UTF-8" DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNvcnJ5LCBDaHJpcy4gSSBzaG91 bGQgaGF2ZSBtYWRlIGl0DQpjbGVhciB0aGF0IHRoaXMgd2FzIGEgZm9ybWFsIHJlcXVlc3QgdG8g SVNPIDYzOS0zIHRvIGNoYW5nZSB0aGlzIHNwZWxsaW5nLg0KSSBjYydlZCB0aGUgTFRSVSBsaXN0 IGZvciBpbmZvcm1hdGlvbiBvbmx5LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPkkgd2Fzbid0IGFkZHJlc3NpbmcgYW55IGNvbmNlcm5zIHdpdGgNCklT TyA2MzktNiBpbiB0aGUgZS1tYWlsIGJlbG93LCBJIGp1c3Qgd2FudGVkIHRvIG1ha2Ugc3VyZSB0 aGF0IHRoZSBmb2xrcw0KaW4gTFRSVSBrbmV3IEkgaGFkIGFscmVhZHkgc3VibWl0dGVkIHRoaXMg Y2hhbmdlIHJlcXVlc3QgYXMgcGVyIGFuIGVhcmxpZXINCnRocmVhZC4gRXRobm9sb2d1ZSBzZWVt cyB0byBoYXZlIHRoaXMgcmlnaHQgc28gSSdtIG5vdCBzdXJlIHlvdSBoYXZlIGENCnByb2JsZW0g d2l0aCA2MzktNi4gSSd2ZSBvbmx5IHNlZW4gdGhpcyBpbiA2MzktMy48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5LYXJlbiBCcm9vbWU8L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTQwJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+ JnF1b3Q7Q2hyaXMgQ294JnF1b3Q7ICZsdDtjaHJpcy5jb3hAZ2VvbGFuZy5jb20mZ3Q7PC9iPg0K PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjAxLzE2LzIwMDcgMDE6 MTIgUE08L2ZvbnQ+DQo8dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPlRvPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4mbHQ7S2FyZW5fQnJvb21lQHNwZS5zb255LmNvbSZndDssICZsdDtpc282MzktM0BzaWwub3Jn Jmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Y2M8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmx0cnVAbGlzdHMuaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPlJFOiBbTHRydV0gUXVlc3Rpb24gYWJvdXQgNjM5LTMgdmFsdWUNCiZxdW90O0Nhc3Rp bGxpYW4mcXVvdDs8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+S2FyZW4sPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj5JIGFtIG5vdCBzdXJlIG9mIHRo ZSBwcm9jZXNzDQpmb3IgZGVhbGluZyB3aXRoIHNwZWxsaW5nIG1pc3Rha2VzIGluIHRoZSA2Mzkt NiBkYXRhYmFzZSwgZXNwZWNpYWxseSBzaW5jZQ0KaXQgaGFzIG5vdCB5ZXQgYmVlbiBwdWJsaXNo ZWQgYnV0IGlzIGluIGZpbmFsIHN0YWdlcyBhcyBkZXNjcmliZWQgYnkgUGV0ZXINCnRoZSBvdGhl ciBkYXkgYnV0IEkgdGhpbmsgaXQgaXMgcHJldHR5IGNlcnRhaW4gdGhhdCB0aGUgRW5nbGlzaCBz cGVsbGluZw0KaXMgd2l0aCBvbmUgTCAoSSBjaGVja2VkIHdpdGggYSB2aXNpdCB0byDigJxPbmUg TG9vayBEaWN0aW9uYXJ54oCdIHdoZXJlDQp0aGUgMTMgbGlzdGVkIGRpY3Rpb25hcmllcyBnYXZl IHRoYXQgc3BlbGxpbmcsIHdoZXJlYXMgYW4gZW50cnkgd2l0aCB0d28NCkxMcyBnYXZlIG9ubHkg b25lIGhpdCBhbmQgdGhhdCB3YXMgdGhlIFdpa2lwZWRpYSBkaXNhbWJpZ3VhdGlvbiBwYWdlIGZv cg0KdGhlIG5hbWUgc3BlbHQgd2l0aCBvbmUgTCkuICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+UmVnYXJkczwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+Q2hyaXM8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxkaXYg YWxpZ249Y2VudGVyPg0KPGJyPg0KPGhyPjwvZGl2Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJU YWhvbWEiPjxiPkZyb206PC9iPiBLYXJlbl9Ccm9vbWVAc3BlLnNvbnkuY29tIFttYWlsdG86S2Fy ZW5fQnJvb21lQHNwZS5zb255LmNvbV0NCjxiPjxicj4NClNlbnQ6PC9iPiAxNiBKYW51YXJ5IDIw MDcgMTg6NTU8Yj48YnI+DQpUbzo8L2I+IGlzbzYzOS0zQHNpbC5vcmc8Yj48YnI+DQpDYzo8L2I+ IGx0cnVAbGlzdHMuaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gW0x0cnVdIFF1ZXN0aW9u IGFib3V0IDYzOS0zIHZhbHVlICZxdW90O0Nhc3RpbGxpYW4mcXVvdDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUbyBXaG9tIEl0IE1heSBDb25jZXJuLDwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpJIGhhdmUgYSBxdWVzdGlvbiBhYm91 dCB0aGUgcmVmZXJlbmNlIG5hbWUgdXNlZCBpbiBJU08gNjM5LTMgZm9yIHRoZSBjb2RlDQomcXVv dDtzcGEuJnF1b3Q7IDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClRoZSBuYW1l IGlzIG5vdyBsaXN0ZWQgYXMgJnF1b3Q7Q2FzdGlsbGlhbiZxdW90OyBhbmQgSSBiZWxpZXZlIHRo aXMgdG8NCmJlIGEgbWlzc3BlbGxpbmcuIFRoZSBjb3JyZWN0IHNwZWxsaW5nIGluIEVuZ2xpc2gg aXMgJnF1b3Q7Q2FzdGlsaWFuJnF1b3Q7DQphcyBmb3VuZCBpbiBJU08gNjM5LTIgYW5kIG9uIHRo ZSBFdGhub2xvZ3VlIHNpdGUuIFRoZSBTcGFuaXNoIGFuZCBGcmVuY2gNCnNwZWxsaW5ncyAtLSBj YXN0ZWxsYW5vIGFuZCBjYXN0aWxsYW4gLS0gdXNlIHR3byBMJ3MsIGJ1dCBJIGJlbGlldmUgdGhl DQp0ZXJtIHNob3VsZCBiZSBzcGVsbGVkIHdpdGggb25lIEwgaW4gRW5nbGlzaC48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtS ZWZlcmVuY2UgVVJMOiA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgaHR0cDovL3d3dy5zaWwu b3JnL2lzbzYzOSUyRDMvZG9jdW1lbnRhdGlvbi5hc3A/aWQ9c3BhPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj48YnI+DQpTaG91bGQgdGhpcyBuYW1lIGJlIHVwZGF0ZWQ/PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpSZWdhcmRzLDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQpLYXJlbiBCcm9vbWU8YnI+DQpNZXRhZGF0YSBTeXN0ZW1zIERlc2ln bmVyPGJyPg0KU29ueSBQaWN0dXJlcyBFbnRlcnRhaW5tZW50PGJyPg0KMzEwLjI0NC40Mzg0PC9m b250Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpMdHJ1IG1haWxpbmcgbGlzdDxicj4NCkx0cnVAaWV0Zi5vcmc8YnI+ DQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1PGJyPg0KPC9mb250 PjwvdHQ+DQo8YnI+DQo= --=_alternative 007B51EF88257265_=-- --===============1591938176== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1591938176==-- From ltru-bounces@ietf.org Tue Jan 16 17:36:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wv6-0003R9-Ne; Tue, 16 Jan 2007 17:36:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wv5-0003Q0-CE for ltru@lists.ietf.org; Tue, 16 Jan 2007 17:36:43 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wv3-00062a-KK for ltru@lists.ietf.org; Tue, 16 Jan 2007 17:36:43 -0500 Received: from MikeLaptop ([82.69.111.196]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 16 Jan 2007 22:36:38 +0000 From: "Chris Cox" To: References: <000901c739b3$120f72c0$6400a8c0@MikeLaptop> Subject: RE: [Ltru] Question about 639-3 value "Castillian" Date: Tue, 16 Jan 2007 22:36:39 -0000 Message-ID: <000a01c739be$c9e81c70$6400a8c0@MikeLaptop> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acc5veGb5oZztTSDS/CMfJUmX0K87wAAHbkg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 233de1b21593fc0f4cdf285406dca0da Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2080336973==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============2080336973== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C739BE.C9E9A310" This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C739BE.C9E9A310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Karen, Worse, I didn't recognise it for what it was but also my reference to 639-6 was a "typo" on my behalf - I was (in my mind) only ever addressing your reference to 639-3. Apologies to all. Chris _____ From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] Sent: 16 January 2007 22:25 To: Chris Cox Cc: ltru@lists.ietf.org Subject: RE: [Ltru] Question about 639-3 value "Castillian" Sorry, Chris. I should have made it clear that this was a formal request to ISO 639-3 to change this spelling. I cc'ed the LTRU list for information only. I wasn't addressing any concerns with ISO 639-6 in the e-mail below, I just wanted to make sure that the folks in LTRU knew I had already submitted this change request as per an earlier thread. Ethnologue seems to have this right so I'm not sure you have a problem with 639-6. I've only seen this in 639-3. Regards, Karen Broome "Chris Cox" 01/16/2007 01:12 PM To , cc ltru@lists.ietf.org Subject RE: [Ltru] Question about 639-3 value "Castillian" Karen, I am not sure of the process for dealing with spelling mistakes in the 639-6 database, especially since it has not yet been published but is in final stages as described by Peter the other day but I think it is pretty certain that the English spelling is with one L (I checked with a visit to "One Look Dictionary" where the 13 listed dictionaries gave that spelling, whereas an entry with two LLs gave only one hit and that was the Wikipedia disambiguation page for the name spelt with one L). Regards Chris _____ From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] Sent: 16 January 2007 18:55 To: iso639-3@sil.org Cc: ltru@lists.ietf.org Subject: [Ltru] Question about 639-3 value "Castillian" To Whom It May Concern, I have a question about the reference name used in ISO 639-3 for the code "spa." The name is now listed as "Castillian" and I believe this to be a misspelling. The correct spelling in English is "Castilian" as found in ISO 639-2 and on the Ethnologue site. The Spanish and French spellings -- castellano and castillan -- use two L's, but I believe the term should be spelled with one L in English. Reference URL: http://www.sil.org/iso639%2D3/documentation.asp?id=spa Should this name be updated? Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384_______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------=_NextPart_000_000B_01C739BE.C9E9A310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Karen,

Worse, I didn’t recognise it = for what it was but also my reference to 639-6 was a “typo” on my behalf = – I was (in my mind) only ever addressing your reference to = 639-3.

Apologies to = all.

Chris

 

From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com]
Sent: 16 January 2007 = 22:25
To: Chris Cox
Cc: = ltru@lists.ietf.org
Subject: RE: [Ltru] = Question about 639-3 value "Castillian"

 


Sorry, Chris. I should have made it clear that = this was a formal request to ISO 639-3 to change this spelling. I cc'ed the = LTRU list for information only. =

I wasn't addressing any concerns with ISO 639-6 in the e-mail below, I = just wanted to make sure that the folks in LTRU knew I had already submitted this change request as per an earlier = thread. Ethnologue seems to have this right so I'm not sure you have a problem = with 639-6. I've only seen this in 639-3.

Regards,

Karen Broome



"Chris Cox" <chris.cox@geolang.com> =

01/16/2007 01:12 PM

To

<Karen_Broome@spe.sony.com>, <iso639-3@sil.org>

cc

ltru@lists.ietf.org =

Subject

RE: [Ltru] Question about 639-3 value "Castillian"

 

 

 




Karen,
I am not sure of the process for dealing with spelling mistakes in the 639-6 database, especially since it has not yet been = published but is in final stages as described by Peter the other day but I think = it is pretty certain that the English spelling is with one L (I checked with a = visit to “One Look Dictionary” where the 13 listed dictionaries = gave that spelling, whereas an entry with two LLs gave only one hit and that was the = Wikipedia disambiguation page for the name spelt with one L).   =
Regards
Chris
 

 


From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com]
Sent: 16 January 2007 18:55
To: iso639-3@sil.org
Cc: ltru@lists.ietf.org
Subject: [Ltru] Question about 639-3 value = "Castillian"
 

To Whom It May Concern,

I have a question about the reference name used in ISO 639-3 for the = code "spa."

The name is now listed as "Castillian" and I believe this to = be a misspelling. The correct spelling in English is "Castilian" as = found in ISO 639-2 and on the Ethnologue site. The Spanish and French = spellings -- castellano and castillan -- use two L's, but I believe the term should = be spelled with one L in English.

       Reference URL:
      = http://www.sil.org/iso639%2D3/documentation.asp?id=3Dspa

Should this name be updated?

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384______________________________________________= _
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

------=_NextPart_000_000B_01C739BE.C9E9A310-- --===============2080336973== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2080336973==-- From ltru-bounces@ietf.org Tue Jan 16 20:14:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6zNe-0000WQ-Jm; Tue, 16 Jan 2007 20:14:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wmQ-0008R3-69 for ltru@lists.ietf.org; Tue, 16 Jan 2007 17:27:46 -0500 Received: from smtp1.wsfo.org ([208.145.81.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wmO-0003dS-Si for ltru@lists.ietf.org; Tue, 16 Jan 2007 17:27:46 -0500 Received: from dfwcom.sil.org (philippi.dallas.sil.org [172.20.1.21]) by smtp1.wsfo.org (8.13.1/8.13.1) with ESMTP id l0GMRchd000402; Tue, 16 Jan 2007 17:27:39 -0500 In-Reply-To: From: ISO639-3@sil.org To: Karen_Broome@spe.sony.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: Date: Tue, 16 Jan 2007 16:27:43 -0600 X-MIMETrack: Serialize by Router on DFWCOM/Servers/WCT(Release 7.0.2|September 26, 2006) at 01/16/2007 04:27:39 PM, Serialize complete at 01/16/2007 04:27:39 PM X-Scanned-By: MIMEDefang 2.54 on 172.22.0.51 X-Spam-Score: 0.3 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 X-Mailman-Approved-At: Tue, 16 Jan 2007 20:14:22 -0500 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Question about 639-3 value "Castillian" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1638838129==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1638838129== Content-Type: multipart/alternative; boundary="=_alternative 007B60CE86257265_=" This is a multipart message in MIME format. --=_alternative 007B60CE86257265_= Content-Type: text/plain; charset="US-ASCII" Dear Karen, Thank you for pointing out the error, which is a misspelling. It will be corrected shortly, in both downloadable tables and the web interface. Joan Spanne ISO 639-3/RA SIL International 7500 W Camp Wisdom Rd Dallas, TX 75236 ISO639-3@sil.org Karen_Broome@spe.sony.com 01/16/2007 12:54 PM To iso639-3@sil.org cc ltru@lists.ietf.org Subject Question about 639-3 value "Castillian" To Whom It May Concern, I have a question about the reference name used in ISO 639-3 for the code "spa." The name is now listed as "Castillian" and I believe this to be a misspelling. The correct spelling in English is "Castilian" as found in ISO 639-2 and on the Ethnologue site. The Spanish and French spellings -- castellano and castillan -- use two L's, but I believe the term should be spelled with one L in English. Reference URL: http://www.sil.org/iso639%2D3/documentation.asp?id=spa Should this name be updated? Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 --=_alternative 007B60CE86257265_= Content-Type: text/html; charset="US-ASCII"
Dear Karen,

Thank you for pointing out the error, which is a misspelling. It will be corrected shortly, in both downloadable tables and the web interface.

Joan Spanne
ISO 639-3/RA
SIL International
7500 W Camp Wisdom Rd
Dallas, TX 75236
ISO639-3@sil.org


Karen_Broome@spe.sony.com

01/16/2007 12:54 PM

To
iso639-3@sil.org
cc
ltru@lists.ietf.org
Subject
Question about 639-3 value "Castillian"






To Whom It May Concern,

I have a question about the reference name used in ISO 639-3 for the code "spa."

The name is now listed as "Castillian" and I believe this to be a misspelling. The correct spelling in English is "Castilian" as found in ISO 639-2 and on the Ethnologue site. The Spanish and French spellings -- castellano and castillan -- use two L's, but I believe the term should be spelled with one L in English.

       Reference URL:
      http://www.sil.org/iso639%2D3/documentation.asp?id=spa

Should this name be updated?

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384
--=_alternative 007B60CE86257265_=-- --===============1638838129== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1638838129==-- From ltru-bounces@ietf.org Thu Jan 18 13:29:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7c0U-0003wk-Um; Thu, 18 Jan 2007 13:29:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7btS-0008Bc-LH for ltru@lists.ietf.org; Thu, 18 Jan 2007 13:21:46 -0500 Received: from smtp1.wsfo.org ([208.145.81.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7btR-0006SP-69 for ltru@lists.ietf.org; Thu, 18 Jan 2007 13:21:46 -0500 Received: from dfwcom.sil.org (philippi.dallas.sil.org [172.20.1.21]) by smtp1.wsfo.org (8.13.1/8.13.1) with ESMTP id l0IILCYa000993; Thu, 18 Jan 2007 13:21:12 -0500 In-Reply-To: <000901c739b3$120f72c0$6400a8c0@MikeLaptop> From: ISO639-3@sil.org To: "Chris Cox" Subject: RE: [Ltru] Question about 639-3 value "Castillian" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: Date: Thu, 18 Jan 2007 12:21:14 -0600 X-MIMETrack: Serialize by Router on DFWCOM/Servers/WCT(Release 7.0.2|September 26, 2006) at 01/18/2007 12:21:13 PM, Serialize complete at 01/18/2007 12:21:13 PM X-Scanned-By: MIMEDefang 2.54 on 172.22.0.51 X-Spam-Score: 0.3 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f X-Mailman-Approved-At: Thu, 18 Jan 2007 13:29:00 -0500 Cc: Karen_Broome@spe.sony.com, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1902195943==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1902195943== Content-Type: multipart/alternative; boundary="=_alternative 0064CFD886257267_=" This is a multipart message in MIME format. --=_alternative 0064CFD886257267_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpUaGlzIHdhcyBhIG1pc3NwZWxsaW5nIGluIHRoZSBJU08gNjM5LTMgRkRJUyBj b2RlIHRhYmxlLiBTaW5jZSBpdCBpcyANCiJjb3JyZWN0IiBpbiA2MzktMiwgYW5kIHNpbmNlIDYz OS0zIGlzIGNvbW1pdHRlZCB0byBoYXZpbmcgYWxsIFBhcnQgMiANCkVuZ2xpc2ggbmFtZXMgaW4g dGhlIFBhcnQgMyBkYXRhIHNldCwgYW5kIHNpbmNlIHRoaXMgaXMgc3RpbGwgdGhlIEZESVMgYW5k IA0Kbm90IHRoZSBmdWxseSBwdWJsaXNoZWQgNjM5LTMsIEkgdGhvdWdodCBpdCBhcHByb3ByaWF0 ZSB0byBtYWtlIHRoZSBjaGFuZ2UgDQphbmQgcmVwdWJsaXNoIHRoZSBkYXRhIHNldCBhbmQgdGhl IGRvd25sb2FkIHRhYmxlLiBUaGF0IGlzIG5vdyBkb25lIGFuZCANCmF2YWlsYWJsZS4NCg0KVGhl cmUgd2FzIGEgc2ltaWxhciwgdGhvdWdoIHNsaWdodGx5IHN0aWNraWVyLCBxdWVzdGlvbiB3aXRo IHJlZ2FyZCB0byBhIA0KW2dzd10gbmFtZSAiQWxlbWFubmljIiB2cyAiQWxlbWFuaWMuIiBBZ2Fp biBrZWVwaW5nIHdpdGggdGhlIG5hbWUgc3BlbGxpbmcgDQphcyBmb3VuZCBpbiA2MzktMiwgSSBj aGFuZ2VkICJBbGVtYW5pYyIgdG8gIkFsZW1hbm5pYy4iDQoNCkJvdGggY29ycmVjdGlvbnMgYXJl IG5vdyB2aXNpYmxlIG9uIHRoZSB3ZWJzaXRlLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkpvYW4gU3Bh bm5lDQpJU08gNjM5LTMvUkENClNJTCBJbnRlcm5hdGlvbmFsDQo3NTAwIFcgQ2FtcCBXaXNkb20g UmQNCkRhbGxhcywgVFggNzUyMzYNCklTTzYzOS0zQHNpbC5vcmcNCg0KDQoNCiJDaHJpcyBDb3gi IDxjaHJpcy5jb3hAZ2VvbGFuZy5jb20+IA0KMDEvMTYvMjAwNyAwMzoxMiBQTQ0KDQpUbw0KPEth cmVuX0Jyb29tZUBzcGUuc29ueS5jb20+LCA8aXNvNjM5LTNAc2lsLm9yZz4NCmNjDQo8bHRydUBs aXN0cy5pZXRmLm9yZz4NClN1YmplY3QNClJFOiBbTHRydV0gUXVlc3Rpb24gYWJvdXQgNjM5LTMg dmFsdWUgIkNhc3RpbGxpYW4iDQoNCg0KDQoNCg0KDQpLYXJlbiwNCkkgYW0gbm90IHN1cmUgb2Yg dGhlIHByb2Nlc3MgZm9yIGRlYWxpbmcgd2l0aCBzcGVsbGluZyBtaXN0YWtlcyBpbiB0aGUgDQo2 MzktNiBkYXRhYmFzZSwgZXNwZWNpYWxseSBzaW5jZSBpdCBoYXMgbm90IHlldCBiZWVuIHB1Ymxp c2hlZCBidXQgaXMgaW4gDQpmaW5hbCBzdGFnZXMgYXMgZGVzY3JpYmVkIGJ5IFBldGVyIHRoZSBv dGhlciBkYXkgYnV0IEkgdGhpbmsgaXQgaXMgcHJldHR5IA0KY2VydGFpbiB0aGF0IHRoZSBFbmds aXNoIHNwZWxsaW5nIGlzIHdpdGggb25lIEwgKEkgY2hlY2tlZCB3aXRoIGEgdmlzaXQgdG8gDQri gJxPbmUgTG9vayBEaWN0aW9uYXJ54oCdIHdoZXJlIHRoZSAxMyBsaXN0ZWQgZGljdGlvbmFyaWVz IGdhdmUgdGhhdCBzcGVsbGluZywgDQp3aGVyZWFzIGFuIGVudHJ5IHdpdGggdHdvIExMcyBnYXZl IG9ubHkgb25lIGhpdCBhbmQgdGhhdCB3YXMgdGhlIFdpa2lwZWRpYSANCmRpc2FtYmlndWF0aW9u IHBhZ2UgZm9yIHRoZSBuYW1lIHNwZWx0IHdpdGggb25lIEwpLiANClJlZ2FyZHMNCkNocmlzDQog DQoNCkZyb206IEthcmVuX0Jyb29tZUBzcGUuc29ueS5jb20gW21haWx0bzpLYXJlbl9Ccm9vbWVA c3BlLnNvbnkuY29tXSANClNlbnQ6IDE2IEphbnVhcnkgMjAwNyAxODo1NQ0KVG86IGlzbzYzOS0z QHNpbC5vcmcNCkNjOiBsdHJ1QGxpc3RzLmlldGYub3JnDQpTdWJqZWN0OiBbTHRydV0gUXVlc3Rp b24gYWJvdXQgNjM5LTMgdmFsdWUgIkNhc3RpbGxpYW4iDQogDQoNClRvIFdob20gSXQgTWF5IENv bmNlcm4sIA0KDQpJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCB0aGUgcmVmZXJlbmNlIG5hbWUgdXNl ZCBpbiBJU08gNjM5LTMgZm9yIHRoZSBjb2RlIA0KInNwYS4iIA0KDQpUaGUgbmFtZSBpcyBub3cg bGlzdGVkIGFzICJDYXN0aWxsaWFuIiBhbmQgSSBiZWxpZXZlIHRoaXMgdG8gYmUgYSANCm1pc3Nw ZWxsaW5nLiBUaGUgY29ycmVjdCBzcGVsbGluZyBpbiBFbmdsaXNoIGlzICJDYXN0aWxpYW4iIGFz IGZvdW5kIGluIA0KSVNPIDYzOS0yIGFuZCBvbiB0aGUgRXRobm9sb2d1ZSBzaXRlLiBUaGUgU3Bh bmlzaCBhbmQgRnJlbmNoIHNwZWxsaW5ncyAtLSANCmNhc3RlbGxhbm8gYW5kIGNhc3RpbGxhbiAt LSB1c2UgdHdvIEwncywgYnV0IEkgYmVsaWV2ZSB0aGUgdGVybSBzaG91bGQgYmUgDQpzcGVsbGVk IHdpdGggb25lIEwgaW4gRW5nbGlzaC4gDQoNCiAgICAgICAgUmVmZXJlbmNlIFVSTDogDQogICAg ICAgaHR0cDovL3d3dy5zaWwub3JnL2lzbzYzOSUyRDMvZG9jdW1lbnRhdGlvbi5hc3A/aWQ9c3Bh IA0KDQpTaG91bGQgdGhpcyBuYW1lIGJlIHVwZGF0ZWQ/IA0KDQpSZWdhcmRzLCANCg0KS2FyZW4g QnJvb21lDQpNZXRhZGF0YSBTeXN0ZW1zIERlc2lnbmVyDQpTb255IFBpY3R1cmVzIEVudGVydGFp bm1lbnQNCjMxMC4yNDQuNDM4NA0KDQo= --=_alternative 0064CFD886257267_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFsbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoaXMgd2FzIGEgbWlzc3BlbGxp bmcgaW4gdGhlIElTTyA2MzktMw0KRkRJUyBjb2RlIHRhYmxlLiBTaW5jZSBpdCBpcyAmcXVvdDtj b3JyZWN0JnF1b3Q7IGluIDYzOS0yLCBhbmQgc2luY2UgNjM5LTMNCmlzIGNvbW1pdHRlZCB0byBo YXZpbmcgYWxsIFBhcnQgMiBFbmdsaXNoIG5hbWVzIGluIHRoZSBQYXJ0IDMgZGF0YSBzZXQsDQph bmQgc2luY2UgdGhpcyBpcyBzdGlsbCB0aGUgRkRJUyBhbmQgbm90IHRoZSBmdWxseSBwdWJsaXNo ZWQgNjM5LTMsIEkgdGhvdWdodA0KaXQgYXBwcm9wcmlhdGUgdG8gbWFrZSB0aGUgY2hhbmdlIGFu ZCByZXB1Ymxpc2ggdGhlIGRhdGEgc2V0IGFuZCB0aGUgZG93bmxvYWQNCnRhYmxlLiBUaGF0IGlz IG5vdyBkb25lIGFuZCBhdmFpbGFibGUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5UaGVyZSB3YXMgYSBzaW1pbGFyLCB0aG91Z2ggc2xpZ2h0bHkNCnN0 aWNraWVyLCBxdWVzdGlvbiB3aXRoIHJlZ2FyZCB0byBhIFtnc3ddIG5hbWUgJnF1b3Q7QWxlbWFu bmljJnF1b3Q7IHZzDQomcXVvdDtBbGVtYW5pYy4mcXVvdDsgQWdhaW4ga2VlcGluZyB3aXRoIHRo ZSBuYW1lIHNwZWxsaW5nIGFzIGZvdW5kIGluDQo2MzktMiwgSSBjaGFuZ2VkICZxdW90O0FsZW1h bmljJnF1b3Q7IHRvICZxdW90O0FsZW1hbm5pYy4mcXVvdDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJvdGggY29ycmVjdGlvbnMgYXJlIG5vdyB2aXNp YmxlIG9uDQp0aGUgd2Vic2l0ZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkJlc3QgcmVnYXJkcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkpvYW4gU3Bhbm5lPGJyPg0KSVNPIDYzOS0zL1JBPGJyPg0KU0lM IEludGVybmF0aW9uYWw8YnI+DQo3NTAwIFcgQ2FtcCBXaXNkb20gUmQ8YnI+DQpEYWxsYXMsIFRY IDc1MjM2PGJyPg0KSVNPNjM5LTNAc2lsLm9yZzwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NDAlPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtDaHJpcyBDb3gmcXVvdDsgJmx0O2Nocmlz LmNveEBnZW9sYW5nLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+MDEvMTYvMjAwNyAwMzoxMiBQTTwvZm9udD4NCjx0ZCB3aWR0aD01OSU+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+VG88L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtLYXJlbl9Ccm9vbWVAc3BlLnNvbnkuY29t Jmd0OywgJmx0O2lzbzYzOS0zQHNpbC5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5jYzwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O2x0cnVA bGlzdHMuaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0PC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogW0x0cnVdIFF1ZXN0 aW9uIGFib3V0IDYzOS0zIHZhbHVlDQomcXVvdDtDYXN0aWxsaWFuJnF1b3Q7PC9mb250PjwvdGFi bGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAg ZmFjZT0iQXJpYWwiPkthcmVuLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4 MCBmYWNlPSJBcmlhbCI+SSBhbSBub3Qgc3VyZSBvZiB0aGUgcHJvY2Vzcw0KZm9yIGRlYWxpbmcg d2l0aCBzcGVsbGluZyBtaXN0YWtlcyBpbiB0aGUgNjM5LTYgZGF0YWJhc2UsIGVzcGVjaWFsbHkg c2luY2UNCml0IGhhcyBub3QgeWV0IGJlZW4gcHVibGlzaGVkIGJ1dCBpcyBpbiBmaW5hbCBzdGFn ZXMgYXMgZGVzY3JpYmVkIGJ5IFBldGVyDQp0aGUgb3RoZXIgZGF5IGJ1dCBJIHRoaW5rIGl0IGlz IHByZXR0eSBjZXJ0YWluIHRoYXQgdGhlIEVuZ2xpc2ggc3BlbGxpbmcNCmlzIHdpdGggb25lIEwg KEkgY2hlY2tlZCB3aXRoIGEgdmlzaXQgdG8g4oCcT25lIExvb2sgRGljdGlvbmFyeeKAnSB3aGVy ZQ0KdGhlIDEzIGxpc3RlZCBkaWN0aW9uYXJpZXMgZ2F2ZSB0aGF0IHNwZWxsaW5nLCB3aGVyZWFz IGFuIGVudHJ5IHdpdGggdHdvDQpMTHMgZ2F2ZSBvbmx5IG9uZSBoaXQgYW5kIHRoYXQgd2FzIHRo ZSBXaWtpcGVkaWEgZGlzYW1iaWd1YXRpb24gcGFnZSBmb3INCnRoZSBuYW1lIHNwZWx0IHdpdGgg b25lIEwpLiAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFj ZT0iQXJpYWwiPlJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAg ZmFjZT0iQXJpYWwiPkNocmlzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgw IGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8ZGl2IGFsaWduPWNlbnRlcj4NCjxicj4NCjxo cj48L2Rpdj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gS2Fy ZW5fQnJvb21lQHNwZS5zb255LmNvbSBbbWFpbHRvOkthcmVuX0Jyb29tZUBzcGUuc29ueS5jb21d DQo8Yj48YnI+DQpTZW50OjwvYj4gMTYgSmFudWFyeSAyMDA3IDE4OjU1PGI+PGJyPg0KVG86PC9i PiBpc282MzktM0BzaWwub3JnPGI+PGJyPg0KQ2M6PC9iPiBsdHJ1QGxpc3RzLmlldGYub3JnPGI+ PGJyPg0KU3ViamVjdDo8L2I+IFtMdHJ1XSBRdWVzdGlvbiBhYm91dCA2MzktMyB2YWx1ZSAmcXVv dDtDYXN0aWxsaWFuJnF1b3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KVG8gV2hvbSBJdCBNYXkgQ29uY2Vybiw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+PGJyPg0KSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgdGhlIHJlZmVyZW5jZSBuYW1lIHVz ZWQgaW4gSVNPIDYzOS0zIGZvciB0aGUgY29kZQ0KJnF1b3Q7c3BhLiZxdW90OyA8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUaGUgbmFtZSBpcyBub3cgbGlzdGVkIGFzICZxdW90 O0Nhc3RpbGxpYW4mcXVvdDsgYW5kIEkgYmVsaWV2ZSB0aGlzIHRvDQpiZSBhIG1pc3NwZWxsaW5n LiBUaGUgY29ycmVjdCBzcGVsbGluZyBpbiBFbmdsaXNoIGlzICZxdW90O0Nhc3RpbGlhbiZxdW90 Ow0KYXMgZm91bmQgaW4gSVNPIDYzOS0yIGFuZCBvbiB0aGUgRXRobm9sb2d1ZSBzaXRlLiBUaGUg U3BhbmlzaCBhbmQgRnJlbmNoDQpzcGVsbGluZ3MgLS0gY2FzdGVsbGFubyBhbmQgY2FzdGlsbGFu IC0tIHVzZSB0d28gTCdzLCBidXQgSSBiZWxpZXZlIHRoZQ0KdGVybSBzaG91bGQgYmUgc3BlbGxl ZCB3aXRoIG9uZSBMIGluIEVuZ2xpc2guPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UmVmZXJlbmNlIFVSTDogPGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7IGh0dHA6Ly93d3cuc2lsLm9yZy9pc282MzklMkQzL2RvY3VtZW50 YXRpb24uYXNwP2lkPXNwYTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KU2hv dWxkIHRoaXMgbmFtZSBiZSB1cGRhdGVkPzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KUmVnYXJkcyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KS2FyZW4g QnJvb21lPGJyPg0KTWV0YWRhdGEgU3lzdGVtcyBEZXNpZ25lcjxicj4NClNvbnkgUGljdHVyZXMg RW50ZXJ0YWlubWVudDxicj4NCjMxMC4yNDQuNDM4NDwvZm9udD4NCjxicj4NCg== --=_alternative 0064CFD886257267_=-- --===============1902195943== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1902195943==-- From ltru-bounces@ietf.org Fri Jan 19 02:08:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7nrG-0007br-Ox; Fri, 19 Jan 2007 02:08:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7nrF-0007Xf-De for ltru@ietf.org; Fri, 19 Jan 2007 02:08:17 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7nrE-0007TN-3N for ltru@ietf.org; Fri, 19 Jan 2007 02:08:17 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070119070811.PGON28374.mta10.adelphia.net@DGBP7M81>; Fri, 19 Jan 2007 02:08:11 -0500 Message-ID: <005601c73b98$94bd2500$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 18 Jan 2007 23:08:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ISO639-3@sil.org Subject: [Ltru] Re: Question about 639-3 value "Castillian" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Joan Spanne wrote: > This was a misspelling in the ISO 639-3 FDIS code table. Since it is > "correct" in 639-2, and since 639-3 is committed to having all Part 2 > English names in the Part 3 data set, and since this is still the FDIS > and not the fully published 639-3, I thought it appropriate to make > the change and republish the data set and the download table. That is > now done and available. The new "Name Index" file is available at: http://www.sil.org/iso639-3/iso-fdis-639-3_Name_Index_20070116.tab It does include the spelling change to "Castilian" along with some other changes, including the "Alemannic" change mentioned below, but also the addition of "Kyrgyz" as an alternative to "Kirghiz" as shown in 639-2 (although other 639-2 names like "Galician" and "Marshallese" and "Navaho" are still absent), and a few reorderings (for example, among the large group of names for "Old Church Slavonic"). And for some reason, a large number of entries in the Name Index file were moved out of alphabetical order, which makes some automated processing more complex. > There was a similar, though slightly stickier, question with regard to > a [gsw] name "Alemannic" vs "Alemanic." Again keeping with the name > spelling as found in 639-2, I changed "Alemanic" to "Alemannic." Unfortunately, the main Code Set file has not been changed, and that file still shows "Alemanic" as the reference name. I assume this is to be changed, but until it is, draft-4645bis must continue to show the one-N spelling. Anyway, I've started assembling draft-4645bis-02 while waiting for comments on -01. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 19 16:20:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H819a-0000Go-9c; Fri, 19 Jan 2007 16:20:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H819Y-0000G6-Vi for ltru@lists.ietf.org; Fri, 19 Jan 2007 16:20:04 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H819X-0004p8-Kg for ltru@lists.ietf.org; Fri, 19 Jan 2007 16:20:04 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H819W-000428-0X for ltru@lists.ietf.org; Fri, 19 Jan 2007 22:20:02 +0100 Received: from du-001-147.access.de.clara.net ([212.82.227.147]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 22:20:02 +0100 Received: from nobody by du-001-147.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 22:20:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 19 Jan 2007 22:19:24 +0100 Organization: Lines: 9 Message-ID: <45B135DC.2E27@xyzzy.claranet.de> References: <011001c73851$881ac270$6601a8c0@DGBP7M81> <45AB056E.27F@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-147.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Doug Ewell wrote: >> Does anyone know if the newer, "living on the edge" >> version applies the updated boilerplate? > It does, since November (version 1.32pre2). Version 1.32 was released. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 21 01:25:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8W8c-0003NX-Rc; Sun, 21 Jan 2007 01:25:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8W8b-0003NJ-DO for ltru@lists.ietf.org; Sun, 21 Jan 2007 01:25:09 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8W8Z-0001P0-1l for ltru@lists.ietf.org; Sun, 21 Jan 2007 01:25:09 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1H8W8U-00055y-Jm for ltru@lists.ietf.org; Sun, 21 Jan 2007 07:25:02 +0100 Received: from 212.82.251.18 ([212.82.251.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Jan 2007 07:25:02 +0100 Received: from nobody by 212.82.251.18 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Jan 2007 07:25:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 21 Jan 2007 06:50:36 +0100 Organization: Lines: 17 Message-ID: <45B2FF2C.51E9@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.18 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ima@ietf.org, cosmogol@ietf.org, ltru@lists.ietf.org Subject: [Ltru] Re: [EAI] ASCII escapes for Unicode characters X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John C Klensin wrote: [http://tools.ietf.org/html/draft-klensin-unicode-escapes] > With the concurrence of the ADs, discussion has been directed > to the discuss@apps.ietf.org list. If you have comments, > please direct them to that list and _not_ to either of these > two lists. Please propose an _unmoderated_ list for the discussion of this draft. The topic is also interesting for COSMOGOL because it was recently discussed there, for LTRU because we intentionally picked the 􂍅 style there, and maybe it's also relevant for I-D.phillips-record-jar Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 21 01:40:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8WN5-0002Lu-26; Sun, 21 Jan 2007 01:40:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8WN3-0002Lp-Ov for ltru@lists.ietf.org; Sun, 21 Jan 2007 01:40:05 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8WN1-0003DZ-Dw for ltru@lists.ietf.org; Sun, 21 Jan 2007 01:40:05 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1H8WMz-0006Lc-W6 for ltru@lists.ietf.org; Sun, 21 Jan 2007 07:40:01 +0100 Received: from 212.82.251.18 ([212.82.251.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Jan 2007 07:40:01 +0100 Received: from nobody by 212.82.251.18 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Jan 2007 07:40:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 21 Jan 2007 06:50:36 +0100 Organization: Lines: 17 Message-ID: <45B2FF2C.51E9@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.18 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ima@ietf.org, cosmogol@ietf.org, ltru@lists.ietf.org Subject: [Ltru] Re: [EAI] ASCII escapes for Unicode characters X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John C Klensin wrote: [http://tools.ietf.org/html/draft-klensin-unicode-escapes] > With the concurrence of the ADs, discussion has been directed > to the discuss@apps.ietf.org list. If you have comments, > please direct them to that list and _not_ to either of these > two lists. Please propose an _unmoderated_ list for the discussion of this draft. The topic is also interesting for COSMOGOL because it was recently discussed there, for LTRU because we intentionally picked the 􂍅 style there, and maybe it's also relevant for I-D.phillips-record-jar Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 21 03:31:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Y6x-0005aX-0M; Sun, 21 Jan 2007 03:31:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Y6w-0005aS-GR for ltru@ietf.org; Sun, 21 Jan 2007 03:31:34 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8Y6u-0007Y1-84 for ltru@ietf.org; Sun, 21 Jan 2007 03:31:34 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070121083127.IWJW28374.mta10.adelphia.net@DGBP7M81> for ; Sun, 21 Jan 2007 03:31:27 -0500 Message-ID: <009801c73d36$8ad5e370$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 21 Jan 2007 00:31:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ltru] N'Ko again X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The draft 639-3 tables show "N'Ko" with a straight ASCII apostrophe. The current Registry has "Description: N’Ko" and I believe it got that way through registration on the part of ietf-languages. For 4646bis, is it correct to leave "N’Ko" in the Registry, but add "N'Ko" with the ASCII apostrophe, and make that one first in the order due to its role as 639-3 reference name? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 21 10:50:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8exI-0005JW-72; Sun, 21 Jan 2007 10:50:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8exG-0005IS-IL for ltru@ietf.org; Sun, 21 Jan 2007 10:50:02 -0500 Received: from [64.39.15.8] (helo=kabissa.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8evE-000378-D2 for ltru@ietf.org; Sun, 21 Jan 2007 10:47:57 -0500 Received: (qmail 16820 invoked from network); 21 Jan 2007 09:47:48 -0600 Received: from cust180.fastlink.bt (HELO IBM92AA25595C4) (202.89.26.180) by kabissa.org with SMTP; 21 Jan 2007 09:47:48 -0600 From: "Don Osborn" To: "'Doug Ewell'" , "'LTRU Working Group'" References: <009801c73d36$8ad5e370$6601a8c0@DGBP7M81> In-Reply-To: <009801c73d36$8ad5e370$6601a8c0@DGBP7M81> Subject: RE: [Ltru] N'Ko again Date: Sun, 21 Jan 2007 21:16:44 +0530 Message-ID: <071301c73d73$789f55f0$69de01d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acc9NqWmg3ysndcnSUeTTZ95zDSn8wAOSEKQ Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org 2019 being the hex code for headache? Either way it might make sense to = list both, in the manner you suggest. No telling if someone might resort = to 02BC (=3Dmigrane?), but maybe we don't have to go there. N' sort of = functions as a unit in Latin transcriptions of Manding (meaning "I," 1st = person singular), not standardized for the kind of apostrophe used, = AFAIK, even when used as part of the name N'Ko. Don=20 -----Original Message----- From: Doug Ewell [mailto:dewell@adelphia.net]=20 Sent: Sunday, January 21, 2007 2:01 PM To: LTRU Working Group Subject: [Ltru] N'Ko again The draft 639-3 tables show "N'Ko" with a straight ASCII apostrophe.=20 The current Registry has "Description: N’Ko" and I believe it got = that way through registration on the part of ietf-languages. For 4646bis, is it correct to leave "N’Ko" in the Registry, but = add "N'Ko" with the ASCII apostrophe, and make that one first in the = order due to its role as 639-3 reference name? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 = http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jan 21 17:04:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8kmq-0004ll-Ft; Sun, 21 Jan 2007 17:03:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8kmo-0004fI-RN for ltru@lists.ietf.org; Sun, 21 Jan 2007 17:03:38 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H8kmn-0006pT-Cg for ltru@lists.ietf.org; Sun, 21 Jan 2007 17:03:38 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H8kmf-0007Lz-3h for ltru@lists.ietf.org; Sun, 21 Jan 2007 23:03:29 +0100 Received: from du-017-197.access.de.clara.net ([212.82.246.197]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Jan 2007 23:03:29 +0100 Received: from nobody by du-017-197.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Jan 2007 23:03:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 21 Jan 2007 23:02:14 +0100 Organization: Lines: 11 Message-ID: <45B3E2E6.2434@xyzzy.claranet.de> References: <009801c73d36$8ad5e370$6601a8c0@DGBP7M81> 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-017-197.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Ltru] Re: N'Ko again X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > The draft 639-3 tables show "N'Ko" with a straight ASCII apostrophe. > The current Registry has "Description: N’Ko" and I believe it > got that way through registration on the part of ietf-languages. Let the ISO 639 folks figure out how to get their descriptions right - that's not the job of the subtag registry or the subtag review list. You owe me two cents ;-> _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 22 02:23:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8tWc-0008AP-Cw; Mon, 22 Jan 2007 02:23:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8tWa-0008AE-Ln for ltru@ietf.org; Mon, 22 Jan 2007 02:23:28 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8tWZ-00033x-Cq for ltru@ietf.org; Mon, 22 Jan 2007 02:23:28 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070122072324.WESB20139.mta9.adelphia.net@DGBP7M81>; Mon, 22 Jan 2007 02:23:24 -0500 Message-ID: <010101c73df6$33cbc570$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <009801c73d36$8ad5e370$6601a8c0@DGBP7M81> <071301c73d73$789f55f0$69de01d0$@net> Subject: Re: [Ltru] N'Ko again Date: Sun, 21 Jan 2007 23:23:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Frank Ellermann X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Don Osborn wrote: > 2019 being the hex code for headache? Either way it might make sense > to list both, in the manner you suggest. No telling if someone might > resort to 02BC (=migrane?), but maybe we don't have to go there. N' > sort of functions as a unit in Latin transcriptions of Manding > (meaning "I," 1st person singular), not standardized for the kind of > apostrophe used, AFAIK, even when used as part of the name N'Ko. Unicode doesn't appear to have a recommendation for N', but there is a character for 'N (U+0149) that is compatibility-equivalent to U+02BC U+006E. That might be cause for concern since the ietf-languages group got the version with U+2019 into the Registry. Frank Ellermann wrote: > Let the ISO 639 folks figure out how to get their descriptions right - > that's not the job of the subtag registry or the subtag review list. There's no question in my mind that we need to use the spelling from ISO 639-3, which is the one with the ASCII apostrophe. The question is whether to keep the one that ietf-languages added. > You owe me two cents ;-> Get in line, I owe everybody two cents. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 22 02:30:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8tdB-0002d8-J2; Mon, 22 Jan 2007 02:30:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8tdA-0002ak-S1 for ltru@ietf.org; Mon, 22 Jan 2007 02:30:16 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8td8-0004RC-FA for ltru@ietf.org; Mon, 22 Jan 2007 02:30:16 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H8td7-0008SZ-0u; Mon, 22 Jan 2007 02:30:13 -0500 Date: Mon, 22 Jan 2007 02:30:13 -0500 To: Doug Ewell Subject: Re: [Ltru] N'Ko again Message-ID: <20070122073012.GC11448@ccil.org> References: <009801c73d36$8ad5e370$6601a8c0@DGBP7M81> <071301c73d73$789f55f0$69de01d0$@net> <010101c73df6$33cbc570$6601a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010101c73df6$33cbc570$6601a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Frank Ellermann , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Unicode doesn't appear to have a recommendation for N', but there is a > character for 'N (U+0149) that is compatibility-equivalent to U+02BC > U+006E. As the compatibility decomposition indicates, that is 'n, not 'N. It's present in Unicode solely for backward compatibility with some ancient Teletex standard that thought the Afrikaans indefinite article, conventionally written 'n, should have a single character. UTN 27, which is about anomalies in character names, notes that this character is not considered a single *letter*. In any case it has nothing to do with N'Ko. -- If you have ever wondered if you are in hell, John Cowan it has been said, then you are on a well-traveled http://www.ccil.org/~cowan road of spiritual inquiry. If you are absolutely cowan@ccil.org sure you are in hell, however, then you must be on the Cross Bronx Expressway. --Alan Feuer, NYTimes, 2002-09-20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 22 02:39:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8tmT-0006HB-0K; Mon, 22 Jan 2007 02:39:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8tmR-0006H3-4A for ltru@ietf.org; Mon, 22 Jan 2007 02:39:51 -0500 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8tmP-0006in-Q4 for ltru@ietf.org; Mon, 22 Jan 2007 02:39:51 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070122073949.QTFP11551.mta13.adelphia.net@DGBP7M81>; Mon, 22 Jan 2007 02:39:49 -0500 Message-ID: <011901c73df8$7e71f610$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <009801c73d36$8ad5e370$6601a8c0@DGBP7M81> <071301c73d73$789f55f0$69de01d0$@net> <010101c73df6$33cbc570$6601a8c0@DGBP7M81> <20070122073012.GC11448@ccil.org> Subject: Re: [Ltru] N'Ko again Date: Sun, 21 Jan 2007 23:39:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Frank Ellermann X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> Unicode doesn't appear to have a recommendation for N', but there is >> a character for 'N (U+0149) that is compatibility-equivalent to >> U+02BC U+006E. > > As the compatibility decomposition indicates, that is 'n, not 'N. Well, and apparently I couldn't read the word SMALL in the character name anyway. Noted, and thank you for the correction. Don had written something about the sequence N' and I barked up the wrong tree. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 23 00:33:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9EHG-0006W2-DW; Tue, 23 Jan 2007 00:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9EHF-0006Vx-8n for ltru@ietf.org; Tue, 23 Jan 2007 00:33:01 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9EHA-0006KJ-FW for ltru@ietf.org; Tue, 23 Jan 2007 00:33:01 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l0N5WpPE006306 for ; Tue, 23 Jan 2007 14:32:51 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0857_2ab9a7f8_aaa3_11db_89cb_0014221fa3c9; Tue, 23 Jan 2007 14:32:50 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:39485) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 23 Jan 2007 14:32:02 +0900 Message-Id: <6.0.0.20.2.20070122160044.0a6c3500@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 22 Jan 2007 16:01:26 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] N'Ko again In-Reply-To: <009801c73d36$8ad5e370$6601a8c0@DGBP7M81> References: <009801c73d36$8ad5e370$6601a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 17:31 07/01/21, Doug Ewell wrote: >The draft 639-3 tables show "N'Ko" with a straight ASCII apostrophe. The current Registry has "Description: N’Ko" and I believe it got that way through registration on the part of ietf-languages. > >For 4646bis, is it correct to leave "N’Ko" in the Registry, but add "N'Ko" with the ASCII apostrophe, and make that one first in the order due to its role as 639-3 reference name? Fine with me. If we can avoid big discussions about which variant to pick by listing both, I'm all for it. Reagrds, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 23 02:41:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9GHV-0005gO-G2; Tue, 23 Jan 2007 02:41:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9GHU-0005fy-H7 for ltru@ietf.org; Tue, 23 Jan 2007 02:41:24 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9GHR-0008QC-VI for ltru@ietf.org; Tue, 23 Jan 2007 02:41:24 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070123074121.VLNG5532.mta11.adelphia.net@DGBP7M81>; Tue, 23 Jan 2007 02:41:21 -0500 Message-ID: <007a01c73ec1$e05fe660$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <009801c73d36$8ad5e370$6601a8c0@DGBP7M81> <6.0.0.20.2.20070122160044.0a6c3500@localhost> Subject: Re: [Ltru] N'Ko again Date: Mon, 22 Jan 2007 23:41:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: >> For 4646bis, is it correct to leave "N’Ko" in the Registry, >> but add "N'Ko" with the ASCII apostrophe, and make that one first in >> the order due to its role as 639-3 reference name? > > Fine with me. If we can avoid big discussions about which variant to > pick by listing both, I'm all for it. Done. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 23 03:29:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9H1n-0003yb-70; Tue, 23 Jan 2007 03:29:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9H1m-0003yW-Di for ltru@lists.ietf.org; Tue, 23 Jan 2007 03:29:14 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9H1l-0008A4-46 for ltru@lists.ietf.org; Tue, 23 Jan 2007 03:29:14 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 9B77526C21F; Tue, 23 Jan 2007 09:29:03 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 80CBF26C20D; Tue, 23 Jan 2007 09:29:03 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 7400458ED0B; Tue, 23 Jan 2007 09:29:03 +0100 (CET) Date: Tue, 23 Jan 2007 09:29:03 +0100 From: Stephane Bortzmeyer To: ltru@lists.ietf.org Message-ID: <20070123082903.GA28270@nic.fr> References: <45B2FF2C.51E9@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45B2FF2C.51E9@xyzzy.claranet.de> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: discuss@apps.ietf.org Subject: [Ltru] Re: ASCII escapes for Unicode characters X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sun, Jan 21, 2007 at 06:50:36AM +0100, Frank Ellermann wrote a message of 17 lines which said: > for LTRU because we intentionally picked the 􂍅 style there, > and maybe it's also relevant for I-D.phillips-record-jar Although it is far from clear in the I-D text, the discussion about the draft (http://www1.ietf.org/mail-archive/web/discuss/current/msg00411.html) showed that it is intended for *new* protocols only so this draft is probably off-topic for LTRU, unless we decide to switch to a completely new registry format. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 23 16:57:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Te8-00022Y-Lx; Tue, 23 Jan 2007 16:57:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Te6-00021Q-If for ltru@ietf.org; Tue, 23 Jan 2007 16:57:38 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Te3-0004FN-2H for ltru@ietf.org; Tue, 23 Jan 2007 16:57:38 -0500 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 23 Jan 2007 21:57:30 +0000 From: "Debbie Garside" To: , "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] N'Ko again Date: Tue, 23 Jan 2007 21:57:24 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <6.0.0.20.2.20070122160044.0a6c3500@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Acc+sEedYoWrS1MdTji9MSEjcDnXYwAiSKoQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Message-Id: +1 debbie > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 22 January 2007 07:01 > To: Doug Ewell; LTRU Working Group > Subject: Re: [Ltru] N'Ko again > > At 17:31 07/01/21, Doug Ewell wrote: > >The draft 639-3 tables show "N'Ko" with a straight ASCII > apostrophe. The current Registry has "Description: > N’Ko" and I believe it got that way through > registration on the part of ietf-languages. > > > >For 4646bis, is it correct to leave "N’Ko" in the > Registry, but add "N'Ko" with the ASCII apostrophe, and make > that one first in the order due to its role as 639-3 reference name? > > Fine with me. If we can avoid big discussions about which > variant to pick by listing both, I'm all for it. > > Reagrds, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 24 05:41:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9fYn-00030W-33; Wed, 24 Jan 2007 05:40:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9fYl-00030K-At for ltru@lists.ietf.org; Wed, 24 Jan 2007 05:40:55 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9fYh-0004GR-1d for ltru@lists.ietf.org; Wed, 24 Jan 2007 05:40:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 29F1126C1EE; Wed, 24 Jan 2007 11:40:37 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 0CFF326C1E4; Wed, 24 Jan 2007 11:40:37 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id F366D58ED0B; Wed, 24 Jan 2007 11:40:36 +0100 (CET) Date: Wed, 24 Jan 2007 11:40:36 +0100 From: Stephane Bortzmeyer To: Debbie Garside , Doug Ewell Message-ID: <20070124104036.GA7502@nic.fr> References: <002601c73ebe$6d2ecb00$6601a8c0@DGBP7M81> <200701231919.l0NJJlVs015592@pechora1.icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701231919.l0NJJlVs015592@pechora1.icann.org> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ietf-languages@iana.org, ltru@lists.ietf.org Subject: [Ltru] HOWTO register a subtag (Was: rejecting proposals based on syntax X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Tue, Jan 23, 2007 at 04:19:41PM -0000, Debbie Garside wrote a message of 73 lines which said: > This would create an inclusive, friendly forum as opposed to a forum > where we have those in the know and those not in the know. It would > also encourage more people to request the sub tags that they need > and perhaps stop people from creating their own. I believe that is > what standardization is all about. OK, better to light a candle than to complain about obscurity. What do people think of this attempt? http://ltru.generic-nic.net/register-new-subtag.html _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 24 09:20:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9iz3-0003Tg-6u; Wed, 24 Jan 2007 09:20:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9iz2-0003R7-Ce for ltru@lists.ietf.org; Wed, 24 Jan 2007 09:20:16 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9iz0-0001yT-47 for ltru@lists.ietf.org; Wed, 24 Jan 2007 09:20:16 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1H9iys-00069Y-4C; Wed, 24 Jan 2007 09:20:06 -0500 Date: Wed, 24 Jan 2007 09:20:06 -0500 To: Stephane Bortzmeyer Subject: Re: [Ltru] HOWTO register a subtag (Was: rejecting proposals based on syntax Message-ID: <20070124142005.GA20718@ccil.org> References: <002601c73ebe$6d2ecb00$6601a8c0@DGBP7M81> <200701231919.l0NJJlVs015592@pechora1.icann.org> <20070124104036.GA7502@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070124104036.GA7502@nic.fr> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ietf-languages@iana.org, Doug Ewell , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer scripsit: > http://ltru.generic-nic.net/register-new-subtag.html Bravo! This list of suggestions may seem long, but is in the direction of ruthless simplification. 1) Don't even mention language subtags. Too many people will insist that his language variety is a separate language and try to register a language subtag. Just say they have to go through ISO (which is true, even if in principle they might end up back here.) 2) Fill in the value of Type for them. 3) Omit altogether the lines Preferred-Value, Deprecated, and Suppress-Script, which have little or no relevance to variant subtags and will be productive of nothing but confusion. Content-free lines don't end up in the Registry anyhow. 4) Variant subtags beginning with a digit should be 4-8 characters, not just 4, although currently we have only 4-digit ones. 5) Give an example of a tag which is too short. A few minor corrections of idiom: 6) "specially" should be "especially". 7) "People" is treated as a plural noun, so "People in my home town speak". 8) Use "beforehand" instead of "before" in "subscribe to the mailing list before", or else say "in advance". 9) Adjectives of nationality are capitalized in English, thus: "the French language", "the French Academy". This makes no sense, and no other European language does it; but not doing it looks childish in English. 10) "the Middle Ages". 11) "early modern French", without the article. -- John Cowan http://ccil.org/~cowan cowan@ccil.org Mr. Henry James writes fiction as if it were a painful duty. --Oscar Wilde _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 24 10:27:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9k1Z-0001cO-PW; Wed, 24 Jan 2007 10:26:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9k1X-0001Zs-QQ for ltru@ietf.org; Wed, 24 Jan 2007 10:26:55 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9k1W-0007IN-Hg for ltru@ietf.org; Wed, 24 Jan 2007 10:26:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id E228D26C287; Wed, 24 Jan 2007 16:26:42 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id C7C3826C283; Wed, 24 Jan 2007 16:26:42 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id BBB9058E9F0; Wed, 24 Jan 2007 16:26:42 +0100 (CET) Date: Wed, 24 Jan 2007 16:26:42 +0100 From: Stephane Bortzmeyer To: Dave Pawson Message-ID: <20070124152642.GA9440@nic.fr> References: <20061122104703.GA12899@nic.fr> <711a73df0611220550p80ef8bar57c94c39d462932a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <711a73df0611220550p80ef8bar57c94c39d462932a@mail.gmail.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org Subject: [Ltru] Re: Google and marking the languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, Nov 22, 2006 at 01:50:33PM +0000, Dave Pawson wrote a message of 46 lines which said: > Does this group (or the others with similar interests) ever make a > marketing effort? > Where is the list of ten good reasons to id the language? > Where should those who see the benefit point others to, the 'sales pitch'? I am not a salesman and I did not find ten reasons, only three, but here we are: http://ltru.generic-nic.net/why-tagging.html _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 24 10:28:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9k3A-0003Vj-Jk; Wed, 24 Jan 2007 10:28:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9k39-0003Vd-85 for ltru@lists.ietf.org; Wed, 24 Jan 2007 10:28:35 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9k37-0007Yf-Rm for ltru@lists.ietf.org; Wed, 24 Jan 2007 10:28:35 -0500 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 24 Jan 2007 15:28:31 +0000 From: "Debbie Garside" To: , "'Doug Ewell'" Date: Wed, 24 Jan 2007 15:28:26 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20070124104036.GA7502@nic.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Acc/ptVbdWjyyaaYQy6Vx3uzouhePgAJTIUA X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ietf-languages@iana.org, ltru@lists.ietf.org Subject: [Ltru] RE: HOWTO register a subtag (Was: rejecting proposals based on syntax X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Message-Id: Stephane wrote: > OK, better to light a candle than to complain about > obscurity. What do people think of this attempt? > > http://ltru.generic-nic.net/register-new-subtag.html I can only reiterate those who have gone before... Bravo! :-) Best Debbie > -----Original Message----- > From: ietf-languages-bounces@alvestrand.no > [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of > Stephane Bortzmeyer > Sent: 24 January 2007 10:41 > To: Debbie Garside; Doug Ewell > Cc: ietf-languages@iana.org; ltru@lists.ietf.org > Subject: HOWTO register a subtag (Was: rejecting proposals > based on syntax > > On Tue, Jan 23, 2007 at 04:19:41PM -0000, Debbie Garside > wrote a message of 73 lines which said: > > > This would create an inclusive, friendly forum as opposed > to a forum > > where we have those in the know and those not in the know. > It would > > also encourage more people to request the sub tags that > they need and > > perhaps stop people from creating their own. I believe > that is what > > standardization is all about. > > OK, better to light a candle than to complain about > obscurity. What do people think of this attempt? > > http://ltru.generic-nic.net/register-new-subtag.html > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 24 12:20:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9lnF-0007FY-Hu; Wed, 24 Jan 2007 12:20:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9lnE-0007FS-Gg for ltru@ietf.org; Wed, 24 Jan 2007 12:20:16 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9lnD-0007P8-4A for ltru@ietf.org; Wed, 24 Jan 2007 12:20:16 -0500 Received: from [10.72.72.16] (snvvpn1-10-72-72-c16.corp.yahoo.com [10.72.72.16]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l0OHK1OQ099519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jan 2007 09:20:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=2LZok9uUrOK6MT0NKRLz86KKsLZc7u6N0v8voW6AJgUWewVFBkRE84qxA5VzIkLb Message-ID: <45B79541.3060109@yahoo-inc.com> Date: Wed, 24 Jan 2007 09:20:01 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: Google and marking the languages References: <20061122104703.GA12899@nic.fr> <711a73df0611220550p80ef8bar57c94c39d462932a@mail.gmail.com> <20070124152642.GA9440@nic.fr> In-Reply-To: <20070124152642.GA9440@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org You might want to look at some of the W3C GEO material. For example: http://www.w3.org/TR/i18n-html-tech-lang/#ri20050208.091505539 (There list is very similar to yours) Addison Stephane Bortzmeyer wrote: > On Wed, Nov 22, 2006 at 01:50:33PM +0000, > Dave Pawson wrote > a message of 46 lines which said: > >> Does this group (or the others with similar interests) ever make a >> marketing effort? > >> Where is the list of ten good reasons to id the language? > >> Where should those who see the benefit point others to, the 'sales pitch'? > > I am not a salesman and I did not find ten reasons, only three, but > here we are: > > http://ltru.generic-nic.net/why-tagging.html > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 24 12:36:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9m2w-0006pu-Li; Wed, 24 Jan 2007 12:36:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9m2u-0006po-Ea for ltru@ietf.org; Wed, 24 Jan 2007 12:36:28 -0500 Received: from wr-out-0506.google.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9m2s-0002Iw-11 for ltru@ietf.org; Wed, 24 Jan 2007 12:36:28 -0500 Received: by wr-out-0506.google.com with SMTP id 69so202373wra for ; Wed, 24 Jan 2007 09:36:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Xcv2/+jp/LJzfS49bRhfg2zF1jTocsBV9+Zg5Gvi3VHiFCL7lIM2NhpddKFwJFVBd38KoKY8+hsIN4XMDniSNnWL7hBdpmp43tCeEx8mDXZfMhr1WUpTbLNt5l5zcOoHXHs2oMauOkR7r1HNiVI8OWGZ9uEV6nAlVMnocrg2SoU= Received: by 10.90.90.3 with SMTP id n3mr879428agb.1169660185382; Wed, 24 Jan 2007 09:36:25 -0800 (PST) Received: by 10.90.50.20 with HTTP; Wed, 24 Jan 2007 09:36:25 -0800 (PST) Message-ID: <30b660a20701240936u11da22d8ia419eac2369921d2@mail.gmail.com> Date: Wed, 24 Jan 2007 09:36:25 -0800 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: Google and marking the languages In-Reply-To: <45B79541.3060109@yahoo-inc.com> MIME-Version: 1.0 References: <20061122104703.GA12899@nic.fr> <711a73df0611220550p80ef8bar57c94c39d462932a@mail.gmail.com> <20070124152642.GA9440@nic.fr> <45B79541.3060109@yahoo-inc.com> X-Google-Sender-Auth: 5e249067d558ba19 X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0330889028==" Errors-To: ltru-bounces@ietf.org --===============0330889028== Content-Type: multipart/alternative; boundary="----=_Part_73711_2457232.1169660185043" ------=_Part_73711_2457232.1169660185043 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think the key issue is that language tagging, like charset tagging, can be reliable in controlled environments. For example, if documents on the web are being indexed inside a search engine, then once they are properly tagged, that tag can follow them everywhere and be used in a wide variety of processing. So even just from that viewpoint, having a reliable, standard mechanism for language tagging is very valuable. The problem is that the web *in general* (including XML documents) is completely unreliably tagged. Because of that, anyone doing processing of arbitrary documents is forced to take an external document's tag as being little more than a hint, one that can be completely disregarded if it appears to disagree with the actual contents. It is a bit of a chicken-and-egg problem for the web in general. People tend add information to web documents IF the results of adding it matter; the page displays better, or is processed better. - Adding correct language tags right now doesn't have much impact, so people don't add correct language tags. - So search engines, etc, have to disregard the information that is there (except in controlled environments). - So there isn't much impact to not adding correct language tags. - &c. I don't think it is deadlocked. We are seeing more pages be tagged correctly over time, and the higher the percentage, the stronger a weight can be given to the hint. However, I don't know that we'll ever get to the point where the language tag can be completely relied upon for general web documents. Mark On 1/24/07, Addison Phillips wrote: > > You might want to look at some of the W3C GEO material. For example: > > http://www.w3.org/TR/i18n-html-tech-lang/#ri20050208.091505539 > > (There list is very similar to yours) > > Addison > > Stephane Bortzmeyer wrote: > > On Wed, Nov 22, 2006 at 01:50:33PM +0000, > > Dave Pawson wrote > > a message of 46 lines which said: > > > >> Does this group (or the others with similar interests) ever make a > >> marketing effort? > > > >> Where is the list of ten good reasons to id the language? > > > >> Where should those who see the benefit point others to, the 'sales > pitch'? > > > > I am not a salesman and I did not find ten reasons, only three, but > > here we are: > > > > http://ltru.generic-nic.net/why-tagging.html > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_73711_2457232.1169660185043 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think the key issue is that language tagging, like charset tagging, can be reliable in controlled environments. For example, if documents on the web are being indexed inside a search engine, then once they are properly tagged, that tag can follow them everywhere and be used in a wide variety of processing. So even just from that viewpoint, having a reliable, standard mechanism for language tagging is very valuable.

The problem is that the web *in general* (including XML documents) is completely unreliably tagged. Because of that, anyone doing processing of arbitrary documents is forced to take an external document's tag as being little more than a hint, one that can be completely disregarded if it appears to disagree with the actual contents.

It is a bit of a chicken-and-egg problem for the web in general. People tend add information to web documents IF the results of adding it matter; the page displays better, or is processed better.
  • Adding correct language tags right now doesn't have much impact, so people don't add correct language tags.
  • So search engines, etc, have to disregard the information that is there (except in controlled environments).
  • So there isn't much impact to not adding correct language tags.
  • &c.
I don't think it is deadlocked. We are seeing more pages be tagged correctly over time, and the higher the percentage, the stronger a weight can be given to the hint. However, I don't know that we'll ever get to the point where the language tag can be completely relied upon for general web documents.

Mark

On 1/24/07, Addison Phillips <addison@yahoo-inc.com> wrote:
You might want to look at some of the W3C GEO material. For example:

    http://www.w3.org/TR/i18n-html-tech-lang/#ri20050208.091505539

(There list is very similar to yours)

Addison

Stephane Bortzmeyer wrote:
> On Wed, Nov 22, 2006 at 01:50:33PM +0000,
>  Dave Pawson <dave.pawson@gmail.com > wrote
>  a message of 46 lines which said:
>
>> Does this group (or the others with similar interests) ever make a
>> marketing effort?
>
>> Where is the list of ten good reasons to id the language?
>
>> Where should those who see the benefit point others to, the 'sales pitch'?
>
> I am not a salesman and I did not find ten reasons, only three, but
> here we are:
>
> http://ltru.generic-nic.net/why-tagging.html
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru

--
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

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



--
Mark ------=_Part_73711_2457232.1169660185043-- --===============0330889028== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0330889028==-- From ltru-bounces@ietf.org Wed Jan 24 15:00:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9oHw-0007TX-J0; Wed, 24 Jan 2007 15:00:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9oHv-0007Sv-4H for ltru@ietf.org; Wed, 24 Jan 2007 15:00:07 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9oHs-00052R-Cz for ltru@ietf.org; Wed, 24 Jan 2007 15:00:07 -0500 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 24 Jan 2007 20:00:02 +0000 From: "Debbie Garside" To: , "'Addison Phillips'" , Subject: RE: [Ltru] Re: Google and marking the languages Date: Wed, 24 Jan 2007 19:59:57 -0000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <30b660a20701240936u11da22d8ia419eac2369921d2@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Acc/3mE8pUimLaI/SDahBLqv4dMAIwAE1WqQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1718674968==" Errors-To: ltru-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============1718674968== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0172_01C73FF2.39429990" This is a multi-part message in MIME format. ------=_NextPart_000_0172_01C73FF2.39429990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I believe I have already given my considered opinion on this topic... as a marketing consultant (my original trade) with some 24 years experience... but hey ho, each to his own! Standards need marketing the same as any other product or service! Debbie _____ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: 24 January 2007 17:36 To: Addison Phillips Cc: ltru@ietf.org Subject: Re: [Ltru] Re: Google and marking the languages I think the key issue is that language tagging, like charset tagging, can be reliable in controlled environments. For example, if documents on the web are being indexed inside a search engine, then once they are properly tagged, that tag can follow them everywhere and be used in a wide variety of processing. So even just from that viewpoint, having a reliable, standard mechanism for language tagging is very valuable. The problem is that the web *in general* (including XML documents) is completely unreliably tagged. Because of that, anyone doing processing of arbitrary documents is forced to take an external document's tag as being little more than a hint, one that can be completely disregarded if it appears to disagree with the actual contents. It is a bit of a chicken-and-egg problem for the web in general. People tend add information to web documents IF the results of adding it matter; the page displays better, or is processed better. * Adding correct language tags right now doesn't have much impact, so people don't add correct language tags. * So search engines, etc, have to disregard the information that is there (except in controlled environments). * So there isn't much impact to not adding correct language tags. * &c. I don't think it is deadlocked. We are seeing more pages be tagged correctly over time, and the higher the percentage, the stronger a weight can be given to the hint. However, I don't know that we'll ever get to the point where the language tag can be completely relied upon for general web documents. Mark On 1/24/07, Addison Phillips wrote: You might want to look at some of the W3C GEO material. For example: http://www.w3.org/TR/i18n-html-tech-lang/#ri20050208.091505539 (There list is very similar to yours) Addison Stephane Bortzmeyer wrote: > On Wed, Nov 22, 2006 at 01:50:33PM +0000, > Dave Pawson > wrote > a message of 46 lines which said: > >> Does this group (or the others with similar interests) ever make a >> marketing effort? > >> Where is the list of ten good reasons to id the language? > >> Where should those who see the benefit point others to, the 'sales pitch'? > > I am not a salesman and I did not find ten reasons, only three, but > here we are: > > http://ltru.generic-nic.net/why-tagging.html > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- Mark ------=_NextPart_000_0172_01C73FF2.39429990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 believe I have already given my considered opinion on this topic... as a = marketing consultant (my original trade) with some 24 years = experience... but=20 hey ho, each to his own! 
 
Standards need marketing the same as any other product or=20 service!
 
Debbie
 
 

From: Mark Davis=20 [mailto:mark.davis@icu-project.org]
Sent: 24 January 2007=20 17:36
To: Addison Phillips
Cc:=20 ltru@ietf.org
Subject: Re: [Ltru] Re: Google and marking the = languages

I think the key issue is that language tagging, like = charset=20 tagging, can be reliable in controlled environments. For example, if = documents=20 on the web are being indexed inside a search engine, then once they = are=20 properly tagged, that tag can follow them everywhere and be used in a = wide=20 variety of processing. So even just from that viewpoint, having a = reliable,=20 standard mechanism for language tagging is very valuable.

The = problem=20 is that the web *in general* (including XML documents) is completely=20 unreliably tagged. Because of that, anyone doing processing of = arbitrary=20 documents is forced to take an external document's tag as being little = more=20 than a hint, one that can be completely disregarded if it appears to = disagree=20 with the actual contents.

It is a bit of a chicken-and-egg = problem for=20 the web in general. People tend add information to web documents IF = the=20 results of adding it matter; the page displays better, or is processed = better.=20
  • Adding correct language tags right now doesn't have much impact, = so=20 people don't add correct language tags.=20
  • So search engines, etc, have to disregard the information that = is there=20 (except in controlled environments).
  • So there isn't much impact to not adding correct language tags.
  • &c.
I don't think it is deadlocked. We are = seeing more=20 pages be tagged correctly over time, and the higher the percentage, = the=20 stronger a weight can be given to the hint. However, I don't know that = we'll=20 ever get to the point where the language tag can be completely relied = upon for=20 general web documents.

Mark

On 1/24/07, Addison=20 Phillips <addison@yahoo-inc.com>=20 wrote:
You=20 might want to look at some of the W3C GEO material. For=20 example:

    h= ttp://www.w3.org/TR/i18n-html-tech-lang/#ri20050208.091505539

= (There=20 list is very similar to yours)

Addison

Stephane = Bortzmeyer=20 wrote:
> On Wed, Nov 22, 2006 at 01:50:33PM=20 +0000,
>  Dave Pawson <dave.pawson@gmail.com > = wrote
>  a message of 46 lines which=20 said:
>
>> Does this group (or the others with = similar=20 interests) ever make a
>> marketing = effort?
>
>>=20 Where is the list of ten good reasons to id the language?=20
>
>> Where should those who see the benefit point = others to,=20 the 'sales pitch'?
>
> I am not a salesman and I did not = find=20 ten reasons, only three, but
> here we are:
>
> http://ltru.generic= -nic.net/why-tagging.html
>
>=20 _______________________________________________
> Ltru mailing = list
> Ltru@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/ltru

--
Addison=20 Phillips
Globalization Architect -- Yahoo!=20 Inc.

Internationalization is an architecture.
It is not a = = feature.

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



--
Mark=20 ------=_NextPart_000_0172_01C73FF2.39429990-- --===============1718674968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1718674968==-- From ltru-bounces@ietf.org Wed Jan 24 17:45:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qrx-0001Pr-M1; Wed, 24 Jan 2007 17:45:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qrw-0001L1-8y for ltru@lists.ietf.org; Wed, 24 Jan 2007 17:45:28 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9qrs-0000P7-PV for ltru@lists.ietf.org; Wed, 24 Jan 2007 17:45:28 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H9qrn-0003pD-Bg for ltru@lists.ietf.org; Wed, 24 Jan 2007 23:45:19 +0100 Received: from d253188.dialin.hansenet.de ([80.171.253.188]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Jan 2007 23:45:19 +0100 Received: from nobody by d253188.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Jan 2007 23:45:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 24 Jan 2007 23:43:20 +0100 Organization: Lines: 19 Message-ID: <45B7E108.75FD@xyzzy.claranet.de> References: <002601c73ebe$6d2ecb00$6601a8c0@DGBP7M81> <200701231919.l0NJJlVs015592@pechora1.icann.org> <20070124104036.GA7502@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253188.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: HOWTO register a subtag X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > What do people think of this attempt? Nice. For the "language" case you could say that folks trying this need a very good proposal and the evidence that ISO 639 rejected it. If you want a link to a specific section of RFC 4646 you could use e.g. or later in your text . The required background information should be something better than an ordinary Wikipedia link (a Wikipedia permalink is already better). Would encoding="ISO-8859-1" help with legacy browsers and / or MUAs for the references in the second example ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 25 15:38:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HABLe-0001kO-Kp; Thu, 25 Jan 2007 15:37:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HABLd-0001kI-8R for ltru@ietf.org; Thu, 25 Jan 2007 15:37:29 -0500 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HABLc-0006Pr-0C for ltru@ietf.org; Thu, 25 Jan 2007 15:37:29 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 07D5B24080E; Thu, 25 Jan 2007 21:37:07 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 3D52B133E8; Thu, 25 Jan 2007 21:33:58 +0100 (CET) Date: Thu, 25 Jan 2007 21:33:58 +0100 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20070125203358.GA526@sources.org> References: <20061122104703.GA12899@nic.fr> <711a73df0611220550p80ef8bar57c94c39d462932a@mail.gmail.com> <20070124152642.GA9440@nic.fr> <45B79541.3060109@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45B79541.3060109@yahoo-inc.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org Subject: [Ltru] Re: Google and marking the languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, Jan 24, 2007 at 09:20:01AM -0800, Addison Phillips wrote a message of 36 lines which said: > You might want to look at some of the W3C GEO material. For example: > > http://www.w3.org/TR/i18n-html-tech-lang/#ri20050208.091505539 Thanks for all the comments, an improved version is online. Advices on style and gramamr are also welcome (English is not my main language). Feel free to use it for marketing efforts :-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jan 25 16:07:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HABoQ-0001TO-J9; Thu, 25 Jan 2007 16:07:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HABoO-0001St-Jr for ltru@lists.ietf.org; Thu, 25 Jan 2007 16:07:12 -0500 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HABoN-0001oi-9E for ltru@lists.ietf.org; Thu, 25 Jan 2007 16:07:12 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 59C0724080E; Thu, 25 Jan 2007 22:07:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 37C6F13434; Thu, 25 Jan 2007 22:02:27 +0100 (CET) Date: Thu, 25 Jan 2007 22:02:27 +0100 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20070125210227.GA1175@sources.org> References: <002601c73ebe$6d2ecb00$6601a8c0@DGBP7M81> <200701231919.l0NJJlVs015592@pechora1.icann.org> <20070124104036.GA7502@nic.fr> <45B7E108.75FD@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <45B7E108.75FD@xyzzy.claranet.de> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: HOWTO register a subtag X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, Jan 24, 2007 at 11:43:20PM +0100, Frank Ellermann wrote=20 a message of 25 lines which said: > If you want a link to a specific section of RFC 4646 you could use > e.g. or later in > your text . Great. I hope that tools.ietf.org is perennial. =20 > The required background information should be something better than > an ordinary Wikipedia link (a Wikipedia permalink is already > better). By "permalink", you mean a link to a specific release of the page?=20 Side note: is it better to use a reference to an online page which is freely and easily readable by anyone, but is only a secondary source of information or to the paper book which is the primary source but may be difficult to get? Case study: shoud I support the registration of variant "valencia" with: http://ca.wikipedia.org/wiki/Valenci%C3%A0 (a very good text, very detailed) or with (the same, a specific version, to be sure it is stable): http://ca.wikipedia.org/w/index.php?title=3DValenci%C3%A0&oldid=3D819131 or with: Sanchis i Guarner, Manuel (1934, 1967). La llengua dels valencians. Edicions 3i4, Val=E8ncia 2005. ISBN 84-7502-082-8. > Would encoding=3D"ISO-8859-1" help with legacy browsers and / or MUAs > for the references in the second example ? I switched to US-ASCII and Unicode escapes, John Klensin will be happy :-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 26 10:06:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASeS-0006kt-Lv; Fri, 26 Jan 2007 10:06:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASeR-0006ko-Vv for ltru@lists.ietf.org; Fri, 26 Jan 2007 10:06:03 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HASeP-0002GY-GM for ltru@lists.ietf.org; Fri, 26 Jan 2007 10:06:03 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HASe9-0004n5-4J for ltru@lists.ietf.org; Fri, 26 Jan 2007 16:05:45 +0100 Received: from d254130.dialin.hansenet.de ([80.171.254.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 16:05:45 +0100 Received: from nobody by d254130.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 16:05:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 26 Jan 2007 16:04:19 +0100 Organization: Lines: 65 Message-ID: <45BA1873.117@xyzzy.claranet.de> References: <002601c73ebe$6d2ecb00$6601a8c0@DGBP7M81> <200701231919.l0NJJlVs015592@pechora1.icann.org> <20070124104036.GA7502@nic.fr> <45B7E108.75FD@xyzzy.claranet.de> <20070125210227.GA1175@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254130.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Subject: [Ltru] Re: HOWTO register a subtag X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > Great. I hope that tools.ietf.org is perennial. Among those hoping that are IETF area directors and = Wikipedia (en, meta, maybe more) admins. Henrik's and Bill's IETF tools are cool, and cool URIs never change... :-) >> something better than> an ordinary Wikipedia link >> (a Wikipedia permalink is already better). > By "permalink", you mean a link to a specific release > of the page? Yes, in some of their CSS skins the link is presented = using that name. = = > Side note: is it better to use a reference to an online > page which is freely and easily readable by anyone, but > is only a secondary source of information or to the paper > book which is the primary source but may be difficult to > get? How about both ? If the secondary source is Wikipedia it is supposed to offer good primary sources. Online as an "external link", or offline as "reference". = > http://ca.wikipedia.org/w/index.php?title=3DValenci%C3%A0&oldid=3D81913= 1 I'd prefer that, but of course it's important to convince the subtag review list and especially the expert reviewer. = > or with: > Sanchis i Guarner, Manuel (1934, 1967). La llengua dels > valencians. Edicions 3i4, Val=E8ncia 2005. ISBN 84-7502-082-8. Both are fine, aren't they ? The ISBN style might be soon obsolete, AFAIK they switched to a "new" scheme this year. >> Would encoding=3D"ISO-8859-1" help with legacy browsers >> and / or MUAs for the references in the second example ? = > I switched to US-ASCII and Unicode escapes, John Klensin > will be happy :-) Maybe you're confusing John with my poor old "mozilla 3" :-) Whatever you did, the second example (and the whole page) is still UTF-8, not Latin-1. If folks use a MUA that does not support UTF-8 they might be in trouble. = Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jan 26 10:38:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAT9c-0007JE-EA; Fri, 26 Jan 2007 10:38:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAT9b-0007J9-5q for ltru@lists.ietf.org; Fri, 26 Jan 2007 10:38:15 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAT9Z-00072E-Vs for ltru@lists.ietf.org; Fri, 26 Jan 2007 10:38:15 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1HAT9X-0007IG-2T; Fri, 26 Jan 2007 10:38:11 -0500 Date: Fri, 26 Jan 2007 10:38:11 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: HOWTO register a subtag Message-ID: <20070126153811.GG29815@ccil.org> References: <002601c73ebe$6d2ecb00$6601a8c0@DGBP7M81> <200701231919.l0NJJlVs015592@pechora1.icann.org> <20070124104036.GA7502@nic.fr> <45B7E108.75FD@xyzzy.claranet.de> <20070125210227.GA1175@sources.org> <45BA1873.117@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45BA1873.117@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Both are fine, aren't they ? The ISBN style might be soon > obsolete, AFAIK they switched to a "new" scheme this year. New ISBNs are basically just old ones with "978" prefixed, but the checksum (the final character) has to be recomputed using a new algorithm. ISBN-13s will eventually be assigned with 979 and perhaps other prefixes. These are the values already used on barcodes, and prevent collisions with other types of consumer goods. -- There are three kinds of people in the world: John Cowan those who can count, cowan@ccil.org and those who can't. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 29 09:31:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXXD-0006Ve-VE; Mon, 29 Jan 2007 09:31:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXXC-0006Rg-MR for ltru@ietf.org; Mon, 29 Jan 2007 09:31:02 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBXXB-0002zt-Dq for ltru@ietf.org; Mon, 29 Jan 2007 09:31:02 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070129143100.ZMUR5176.mta9.adelphia.net@DGBP7M81> for ; Mon, 29 Jan 2007 09:31:00 -0500 Message-ID: <001301c743b2$19594930$6801a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 29 Jan 2007 06:31:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] New edition of ISO 3166-1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Just posted to the ISO 3166/MA Web site: "Second edition of ISO 3166-1 published "The new edition of ISO 3166-1 is now published. "This second edition of ISO 3166-1 comprises a consolidation of all changes to the lists of ISO 3166-1:1997 agreed to by the ISO 3166 Maintenance agency, published in the ISO 3166 Newsletter up to V-12." Do we want to reference this new edition in our drafts instead of the 1988 edition? It's 164 Swiss francs (130 U.S. dollars, 101 euros, 67 British pounds) in case anyone has that at their disposal. I have a draft copy but we're not supposed to cite that. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 29 09:52:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXsK-0006Zw-53; Mon, 29 Jan 2007 09:52:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXsI-0006Zp-LL for ltru@lists.ietf.org; Mon, 29 Jan 2007 09:52:50 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBXsD-0006Dm-7C for ltru@lists.ietf.org; Mon, 29 Jan 2007 09:52:50 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HBXrz-0000k9-Hd for ltru@lists.ietf.org; Mon, 29 Jan 2007 15:52:31 +0100 Received: from d255059.dialin.hansenet.de ([80.171.255.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 15:52:31 +0100 Received: from nobody by d255059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 15:52:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 29 Jan 2007 15:52:07 +0100 Organization: Lines: 12 Message-ID: <45BE0A17.2ABF@xyzzy.claranet.de> References: <001301c743b2$19594930$6801a8c0@DGBP7M81> 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: d255059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: New edition of ISO 3166-1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Do we want to reference this new edition in our drafts Yes (we're at 4 cents :-) > I have a draft copy but we're not supposed to cite that. Good enough, unless you find something very unexpected. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jan 29 22:26:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBjdO-0006sd-Em; Mon, 29 Jan 2007 22:26:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBjdN-0006sY-DW for ltru@ietf.org; Mon, 29 Jan 2007 22:26:13 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBjdJ-00086M-I5 for ltru@ietf.org; Mon, 29 Jan 2007 22:26:13 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l0U3Puau015572 for ; Tue, 30 Jan 2007 12:25:56 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 06e9_98ed9a0e_b011_11db_974b_0014221f2a2d; Tue, 30 Jan 2007 12:25:55 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49099) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 30 Jan 2007 12:25:05 +0900 Message-Id: <6.0.0.20.2.20070130115308.0808bd30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 30 Jan 2007 11:54:06 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] New edition of ISO 3166-1 In-Reply-To: <001301c743b2$19594930$6801a8c0@DGBP7M81> References: <001301c743b2$19594930$6801a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 23:31 07/01/29, Doug Ewell wrote: >Just posted to the ISO 3166/MA Web site: > >"Second edition of ISO 3166-1 published > >"The new edition of ISO 3166-1 is now published. > >"This second edition of ISO 3166-1 comprises a consolidation of all changes to the lists of ISO 3166-1:1997 agreed to by the ISO 3166 Maintenance agency, published in the ISO 3166 Newsletter up to V-12." > >Do we want to reference this new edition in our drafts instead of the 1988 edition? It's 164 Swiss francs (130 U.S. dollars, 101 euros, 67 British pounds) in case anyone has that at their disposal. I don't think the previous version was cheaper, so let's cite it. Regards, Martin. >I have a draft copy but we're not supposed to cite that. > >-- >Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 >http://users.adelphia.net/~dewell/ >http://www1.ietf.org/html.charters/ltru-charter.html >http://www.alvestrand.no/mailman/listinfo/ietf-languages > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 30 11:03:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvRS-0004Ww-QA; Tue, 30 Jan 2007 11:02:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvRQ-0004WW-QJ for ltru@ietf.org; Tue, 30 Jan 2007 11:02:40 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBvRH-0005j1-CG for ltru@ietf.org; Tue, 30 Jan 2007 11:02:40 -0500 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 30 Jan 2007 16:02:11 +0000 From: "Debbie Garside" To: , "'LTRU Working Group'" Subject: RE: [Ltru] Submission: draft-ietf-ltru-4645bis-01 Date: Tue, 30 Jan 2007 16:02:07 -0000 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: <010801c7384e$32d14ad0$6601a8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Acc4TxdtXitMn49pRwWo4zwlRCiriQMNlcZg X-Spam-Score: 0.0 (/) X-Scan-Signature: c452ef48b888a0b24ddb6133d8c96a2a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Message-Id: Hi=20 Have read the document in question and all looks well (other than I = would have used "has been" and "is" rather than "was" in a number of places). However, I find the following type of record format in the Registry (for =C1nc=E1 and other records with diacritics) totally unacceptable: %% Type: language Subtag: acb Description: Áncá Added: 2008-01-01 %% I know we have had this discussion before with regard to "Norwegian Bokmål" and "Norwegian Bokmal" and indeed the dreaded apostrophe in N'Ko. Where did we get with it? I would prefer to see both and I had thought this was agreed. There needs to be an element of human = readability within the Registry methinks! Best regards Debbie > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net]=20 > Sent: 15 January 2007 02:38 > To: LTRU Working Group > Subject: [Ltru] Submission: draft-ietf-ltru-4645bis-01 >=20 > I've just submitted draft-ietf-ltru-4645bis-01 to=20 > Internet-Drafts@ietf.org. >=20 > Because this draft is over 802,000 bytes and 916 pages long=20 > -- longer than the previous draft because of the inclusion of=20 > about 1,400 inverted/uninverted pairs -- I was once again=20 > disinclined to post it to the mailing list. Instead, I've=20 > attached a reduced version that includes all of the prose,=20 > but omits most of the proposed new Registry contents. You=20 > can view or download the complete draft at one of the=20 > following locations: >=20 > http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.html > (739,857 bytes) > http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.html.zip > (97,302 bytes) > http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.txt > (857,083 bytes) > http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.txt.zip > (101,713 bytes) >=20 > Of course, once the draft is officially posted to the IETF=20 > site, you can get it there as well. >=20 > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * =20 > UTN #14 http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages >=20 >=20 > -----8<-----cut here-----8<-----cut here-----8<-----cut=20 > here-----8<----- >=20 >=20 > Network Working Group D.=20 > Ewell, Ed. > Internet-Draft =20 > Consultant > Intended status: Informational =20 > January 14, 2007 > Expires: July 18, 2007 >=20 >=20 > Update to the Language Subtag Registry > draft-ietf-ltru-4645bis-01 >=20 > Status of this Memo >=20 > 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. >=20 > 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. >=20 > Internet-Drafts are draft documents valid for a maximum of=20 > six months > and may be updated, replaced, or obsoleted by other=20 > documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. >=20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. >=20 > This Internet-Draft will expire on July 18, 2007. >=20 > Copyright Notice >=20 > Copyright (C) The Internet Society (2007). >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 1] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > Abstract >=20 > This memo defines the procedure used to update the IANA Language > Subtag Registry in conjunction with the publication of RFC 4646bis > [RFC EDITOR NOTE: replace with actual RFC number], for use=20 > in forming > tags for the identification of languages. As an Internet-Draft, it > also contained a complete replacement of the contents of=20 > the Registry > to be used by IANA in updating it. To prevent confusion, this > material was removed before publication. >=20 >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . .=20 > . . . . 3 > 2. Updating the Registry . . . . . . . . . . . . . . . .=20 > . . . . 4 > 2.1. Starting Point . . . . . . . . . . . . . . . . .=20 > . . . . 4 > 2.2. New Subtags . . . . . . . . . . . . . . . . . . .=20 > . . . . 5 > 2.3. Modified Subtags . . . . . . . . . . . . . . . .=20 > . . . . 5 > 2.4. Grandfathered and Redundant Tags . . . . . . . .=20 > . . . . 6 > 2.5. Additional Changes . . . . . . . . . . . . . . .=20 > . . . . 9 > 3. Updated Registry Contents . . . . . . . . . . . . . .=20 > . . . . 10 > 4. Security Considerations . . . . . . . . . . . . . . .=20 > . . . . 909 > 5. IANA Considerations . . . . . . . . . . . . . . . . .=20 > . . . . 910 > 6. Changes . . . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 911 > 7. References . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 912 > 7.1. Normative References . . . . . . . . . . . . . .=20 > . . . . 912 > 7.2. Informative References . . . . . . . . . . . . .=20 > . . . . 912 > Appendix A. Acknowledgements . . . . . . . . . . . . . .=20 > . . . . 914 > Author's Address . . . . . . . . . . . . . . . . . . . .=20 > . . . . 915 > Intellectual Property and Copyright Statements . . . . .=20 > . . . . 916 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 2] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > 1. Introduction >=20 > [RFC4646] provided for a Language Subtag Registry and described its > format. The initial contents of the Registry and rules for > determining them were specified in [RFC4645]. >=20 > [draft-ietf-ltru-4646bis-02] expands on [RFC4646] by adding support > for approximately 7,200 primary and extended language subtags based > on [ISO639-3] alpha-3 code elements. This memo describes=20 > the process > of updating the Registry to include these additional=20 > subtags, and to > make secondary changes to the Registry that result from adding the > new subtags. >=20 > In its initial phase as an Internet-Draft, this memo also=20 > contained a > complete replacement of the contents of the Language=20 > Subtag Registry > to be used by the Internet Assigned Numbers Authority (IANA) in > updating it. This content was deleted from this memo prior to > publication as an RFC. >=20 > The format of the Language Subtag Registry, and the definition and > intended purpose of each of the fields, are described in > [draft-ietf-ltru-4646bis-02]. >=20 > 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 > [draft-ietf-ltru-4646bis-02]. In its Internet-Draft=20 > phase, this memo > did not define the permanent contents of the Registry and=20 > should not > be represented as doing so. >=20 > Many of the subtags defined in the Language Subtag=20 > Registry are based > on code elements defined in [ISO639-1], [ISO639-2], [ISO639-3], > [ISO3166-1], [ISO15924], and [UN_M.49]. The Registry is=20 > not a mirror > of the code lists defined by these standards and should not be used > as one. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 3] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > 2. Updating the Registry >=20 > This section describes the process for determining the updated > contents of the Language Subtag Registry. >=20 > 2.1. Starting Point >=20 > The version of the Language Subtag Registry that was current at the > time of IESG approval of this memo served as the starting point for > this update. The process of creating that version was described in > [RFC4645]. >=20 > The source data for [ISO639-3] used for this update consisted of > three files, available from the official site of the ISO 639-3 > Registration Authority. [RFC EDITOR NOTE: these files are expected > to be updated before approval of this memo.] >=20 > o [iso-fdis-639-3_20061114] is a list of all language=20 > code elements > in [ISO639-3], including the alpha-3 code element and reference > name for each code element. For example, the entry for the Dari > language contained the code element "prs" and the name "Dari" > (among other information). >=20 > o [iso-fdis-639-3_Name_Index_20061114] is a list containing all > names associated with each language according to [ISO639-3], > including both inverted and uninverted forms where=20 > appropriate. A > code element may have more than one entry in this file; the > reference name and its inverted form are usually, but=20 > not always, > given in the first entry. For example, this file contained an > entry for the code element "prs" with the name "Dari"=20 > (twice) and > another entry with the names "Eastern Farsi" and=20 > "Farsi, Eastern". >=20 > o [iso-fdis-639-3-macrolanguages_20061114] is a list of=20 > all alpha-3 > code elements for languages that are encompassed by a > macrolanguage in [ISO639-3], together with the alpha-3 code > element for the macrolanguage. For example, a line=20 > containing the > code elements "fas" and "prs" indicated that the macrolanguage > "Persian" encompasses the individual language "Dari". =20 > (Note that > these alpha-3 code elements may not have corresponded=20 > directly to > subtags in the Registry, which uses 2-letter subtags=20 > derived from > [ISO639-1] when possible.) >=20 > The value of the File-Date field and of the Added date for each new > subtag record are set to a date near the date of IESG approval of > this memo. [RFC EDITOR NOTE: these dates would be updated during > AUTH48.] >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 4] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > 2.2. New Subtags >=20 > For each language in [ISO639-3] that was not already=20 > represented by a > primary language subtag in the Language Subtag Registry, a=20 > new subtag > was added to the Registry, using the [ISO639-3] code element as the > value for the Subtag field and each of the [ISO639-3] names as a > separate Description field. The [ISO639-3] reference name was > represented by the first Description field. The following=20 > rules were > used to determine whether to add a primary or extended language > subtag: >=20 > o If the language was encompassed by a macrolanguage, as=20 > determined > by [iso-fdis-639-3-macrolanguages_20061114], an=20 > extended language > subtag was added, with the primary language subtag of the > macrolanguage as the value for the Prefix field. >=20 > o If the name of the language included the words "Sign=20 > Language", an > extended language subtag was added, with the string "sgn" as the > value for the Prefix field. This is a special case that treats > the existing primary language subtag for "Sign=20 > Languages" as if it > were a macrolanguage encompassing all sign languages. =20 > (Note that > "sgn" is defined as a "collection code" by [ISO639-3]=20 > and hence is > not included in that standard.) >=20 > o Otherwise, a primary language subtag was added. >=20 > All subtags were added to the Registry maintaining=20 > alphabetical order > within each type of tag: all 2-letter "language" subtags=20 > first, then > all 3-letter "language" subtags, and finally all all "extlang" > subtags. Some existing records were moved to ensure this order. >=20 > 2.3. Modified Subtags >=20 > For each language in [ISO639-3] that was already represented by a > primary language subtag in the Language Subtag Registry,=20 > Description > fields were added as necessary to reflect all names listed for that > language (inverted and uninverted) in either > [iso-fdis-639-3_20061114] or [iso-fdis-639-3_Name_Index_20061114]. > The order of Description fields was adjusted to ensure that the > reference name from [ISO639-3] was listed first, followed by other > names from [ISO639-3] in the order presented by that standard, > followed by any other names already existing in the Registry. In > some cases this resulted in a reordering of Description fields for > existing entries, even when no new values were added. >=20 > No existing Description fields were changed or deleted, with the > following exceptions: >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 5] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > o For the primary language subtag "es", the Description=20 > "Castilian" > was replaced by the [ISO639-3] spelling "Castillian". This was > presumed to be an unintentional and temporary mismatch between > [ISO639-2] and [ISO639-3]. >=20 > o For similar reasons, the following spelling changes were made to > existing Description fields in the Registry to bring=20 > them in line > with the corresponding names in [ISO639-3]: >=20 > "gsw" changed from "Alemannic" to "Alemanic" >=20 > "gwi" changed from "Gwich´in" to "Gwich'in" >=20 > "nqo" changed from "N’Ko" to "N'Ko" >=20 > "rup" changed from "Macedo-Romanian" to "Macedo Romanian" >=20 > o The capitalization of the Subtag field for the=20 > redundant tag "yi- > latn" was changed to "yi-Latn" for consistency with the > capitalization conventions described in Section 2.1 of > [draft-ietf-ltru-4646bis-02]. >=20 > 2.4. Grandfathered and Redundant Tags >=20 > As stated in [draft-ietf-ltru-4646bis-02], "grandfathered" and > "redundant" tags are complete tags in the Language Subtag Registry > that were registered under [RFC1766] or [RFC3066] and remain valid. > Grandfathered tags cannot be generated from a valid combination of > subtags, while "redundant" tags can be. >=20 > Under certain conditions, registration of a subtag under > [draft-ietf-ltru-4646bis-02] may cause a grandfathered tag to be > reclassified as redundant. It may also enable the creation of a > generative tag with the same meaning as a grandfathered or=20 > redundant > tag; in that case, the grandfathered or redundant tag is marked as > Deprecated, and the generative tag (including the new=20 > subtag) becomes > its Preferred-Value. >=20 > As a result of adding the new subtags in this update, the following > grandfathered tags became composable and were reclassified as > redundant: >=20 > zh-cmn >=20 > zh-cmn-Hans >=20 > zh-cmn-Hant >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 6] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > zh-gan >=20 > zh-wuu >=20 > zh-yue >=20 > The following grandfathered tags were deprecated, with the=20 > indicated > generative tag serving as the Preferred-Value: >=20 > i-ami (Preferred-Value: ami) >=20 > i-bnn (Preferred-Value: bnn) >=20 > i-pwn (Preferred-Value: pwn) >=20 > i-tao (Preferred-Value: tao) >=20 > i-tay (Preferred-Value: tay) >=20 > i-tsu (Preferred-Value: tsu) >=20 > sgn-CH-de (Preferred-Value: sgn-sgg) >=20 > zh-hakka (Preferred-Value: zh-hak) >=20 > zh-min (no Preferred-Value; see below) >=20 > zh-min-nan (Preferred-Value: zh-nan) >=20 > zh-xiang (Preferred-Value: zh-hns) >=20 > The tag "zh-min", originally registered under [RFC1766],=20 > is a special > case: it represents a small class of languages, but is not a true > macrolanguage. It could not ever become a generative tag since the > [ISO639-3] code element "min" is assigned to an individual language > (Minangkabau) that is not related to Chinese ("zh"). Because it is > not believed to represent a useful linguistic entity for tagging > purposes, it was deprecated without a Preferred-Value. >=20 > The following redundant sign-language tags were=20 > deprecated, with the > indicated generative tag serving as the Preferred-Value: >=20 > sgn-BR (Preferred-Value: sgn-bzs) >=20 > sgn-CO (Preferred-Value: sgn-csn) >=20 > sgn-DE (Preferred-Value: sgn-gsg) >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 7] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > sgn-DK (Preferred-Value: sgn-dsl) >=20 > sgn-ES (Preferred-Value: sgn-ssp) >=20 > sgn-FR (Preferred-Value: sgn-fsl) >=20 > sgn-GB (Preferred-Value: sgn-bfi) >=20 > sgn-GR (Preferred-Value: sgn-gss) >=20 > sgn-IE (Preferred-Value: sgn-isg) >=20 > sgn-IT (Preferred-Value: sgn-ise) >=20 > sgn-JP (Preferred-Value: sgn-jsl) >=20 > sgn-MX (Preferred-Value: sgn-mfs) >=20 > sgn-NI (Preferred-Value: sgn-ncs) >=20 > sgn-NL (Preferred-Value: sgn-dse) >=20 > sgn-NO (Preferred-Value: sgn-nsl) >=20 > sgn-PT (Preferred-Value: sgn-psr) >=20 > sgn-SE (Preferred-Value: sgn-swl) >=20 > sgn-US (Preferred-Value: sgn-ase) >=20 > sgn-ZA (Preferred-Value: sgn-sfs) >=20 > No change was made to the Description field(s) for any of the > grandfathered or redundant tags. For example, the redundant tag > "sgn-US" continues to carry the Description "American Sign=20 > Language". > The sign language tags registered prior to [RFC4646] remain an > exception to the general principle that the meaning of a non- > grandfathered tag can be derived from its component subtags. >=20 > In previous versions of the Registry, grandfathered tags that had > been deprecated as a result of adding an ISO 639-based language > subtag included a Comments field, with a value of the form=20 > "replaced > by ISO code xxx", where "xxx" represented the new language subtag. > These comments duplicated the information contained within the > Preferred-Value field, and were deleted as part of this update. No > changes were made to other Comments fields. >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 8] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > 2.5. Additional Changes >=20 > For consistency with the handling of alternative names in language > subtags, Description fields for script subtags taken from=20 > [ISO15924] > that represent alternative names were converted to multiple > Description fields. For example, the Description "Han=20 > (Hanzi, Kanji, > Hanja)" was converted to four separate Description fields. Some > Description fields for script subtags contained parenthetical > material that was explanatory, rather than identifying alternative > names; these fields were not altered. >=20 > The situation does not apply to region subtags taken from=20 > [ISO3166-1] > and [UN_M.49] because those standards do not provide=20 > freely available > alternative names for code elements. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 9] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > 3. Updated Registry Contents >=20 > The remainder of this section specified the updated set of records > for the Language Subtag Registry. This material was deleted before > publication of this memo, to avoid any potential confusion with the > Registry itself. The IANA Language Subtag Registry can be found at > under "Language Tags". >=20 > [RFC EDITOR NOTE: the remainder of this section is to be=20 > deleted upon > publication.] >=20 > The updated contents of the Language Subtag Registry follow. This > data is intended as a complete replacement for the current contents > of the Registry. The Registry begins with the line that=20 > 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. >=20 > File-Date: 2008-01-01 > %% > Type: language > Subtag: aa > Description: Afar > Added: 2005-10-16 > %% > Type: language > Subtag: ab > Description: Abkhazian > Added: 2005-10-16 > Suppress-Script: Cyrl > %% > Type: language > Subtag: ae > Description: Avestan > Added: 2005-10-16 > %% > Type: language > Subtag: af > Description: Afrikaans > Added: 2005-10-16 > Suppress-Script: Latn > %% > Type: language > Subtag: ak > Description: Akan > Added: 2005-10-16 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 10] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > Description: Cantonese > Added: 1999-12-18 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 908] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > 4. Security Considerations >=20 > For security considerations relevant to the Language=20 > Subtag Registry > and the use of language tags, see [draft-ietf-ltru-4646bis-02]. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 909] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > 5. IANA Considerations >=20 > In its initial phase as an Internet-Draft, this memo contained a > complete replacement of the contents of the Language=20 > Subtag Registry > to be used by IANA in updating it. As an RFC, it contains=20 > a pointer > to the Registry, which is maintained by IANA. The Language Subtag > Registry can be found at under > "Language Tags". For details on the procedures for the format and > ongoing maintenance of this Registry, see > [draft-ietf-ltru-4646bis-02]. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 910] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > 6. Changes >=20 > [Editor's Note: This section is provided for the convenience of > reviewers and will be removed from the final document.] >=20 > This memo is a new work, not an incremental update. The procedure > for populating the original Language Subtag Registry, specified by > the earlier [RFC4646], is included by reference to [RFC4645]. > Therefore, no changes from [RFC4645] are listed in this section. >=20 > Changes between draft-ietf-ltru-4645bis-00 and this version are: >=20 > o Changed procedure to incorporate data from new "Language Names > Index" file and to ensure that the [ISO639-3] reference name is > the first Description field. >=20 > o Removed some exceptions as a result of improved [ISO639-3] draft > data. >=20 > o Removed section dealing with special handling of "(generic)" and > "(specific)" strings within language names. >=20 > o Added an explanation of the process of converting a compound > Description field for a script subtag to multiple Description > fields. >=20 > o Removed Comments fields of the form "replaced by ISO code xxx", > which provided no additional information beyond the Preferred- > Value field. >=20 > o Clarified that the included Registry contents are a complete > replacement for the existing Registry, not a set of deltas. (J. > Cowan) >=20 > o Changed "included within" a macrolanguage to use=20 > "encompassed by" > throughout. (J. Cowan) >=20 > o Provided better explanation for deprecation of "zh-min" in > Section 2.4. (J. Cowan) >=20 > o Added Changes and Acknowledgements sections. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 911] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > 7. References >=20 > 7.1. Normative References >=20 > [ISO639-3] > International Organization for Standardization,=20 > "ISO/FDIS > 639-3:2007. Codes for the representation of names of > languages -- Part 3: Alpha-3 code for comprehensive > coverage of languages, first edition", 2007. >=20 > [draft-ietf-ltru-4646bis-02] > Phillips, A., Ed. and M. Davis, Ed., "Tags for=20 > Identifying > Languages", December 2006, ID/draft-ietf-ltru-4646bis-02.html>. >=20 > [iso-fdis-639-3-macrolanguages_20061114] > International Organization for Standardization,=20 > "ISO/FDIS > 639-3 Macrolanguage Mappings", November 2006, www.sil.org/iso639-3/ > iso-fdis-639-3-macrolanguages_20061114.tab>. >=20 > [iso-fdis-639-3_20061114] > International Organization for Standardization,=20 > "ISO/FDIS > 639-3 Code Set", November 2006, > =20 > . >=20 > [iso-fdis-639-3_Name_Index_20061114] > International Organization for Standardization,=20 > "ISO/FDIS > 639-3 Language Names Index", November 2006, www.sil.org/iso639-3/ > iso-fdis-639-3_Name_Index_20061114.tab>. >=20 > 7.2. Informative References >=20 > [ISO15924] > International Organization for Standardization, "ISO > 15924:2004. Information and documentation -- Codes for > the representation of names of scripts", January 2004. >=20 > [ISO3166-1] > International Organization for Standardization,=20 > "ISO 3166: > 1988. Codes for the representation of names of=20 > countries, > 3rd edition", August 1988. >=20 > [ISO639-1] > International Organization for Standardization,=20 > "ISO 639- > 1:2002. Codes for the representation of names of > languages -- Part 1: Alpha-2 code", 2002. >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 912] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > [ISO639-2] > International Organization for Standardization,=20 > "ISO 639- > 2:1998. Codes for the representation of names of > languages -- Part 2: Alpha-3 code, first edition", 1998. >=20 > [RFC1766] Alvestrand, H., "Tags for the Identification of > Languages", RFC 1766, March 1995. >=20 > [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, > June 1999. >=20 > [RFC3066] Alvestrand, H., "Tags for the Identification of > Languages", RFC 3066, January 2001. >=20 > [RFC4645] Ewell, D., "Initial Language Subtag Registry", RFC 4645, > September 2006. >=20 > [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying > Languages", BCP 47, RFC 4646, September 2006. >=20 > [UN_M.49] Statistics Division, United Nations, "Standard=20 > Country or > Area Codes for Statistical Use", UN Standard Country or > Area Codes for Statistical Use, Revision 4=20 > (United Nations > publication, Sales No. 98.XVII.9), June 1999. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 913] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > Appendix A. Acknowledgements >=20 > This memo is a collaborative work of the Language Tag=20 > Registry Update > (LTRU) Working Group. All of its members have made significant > contributions to this memo and to its predecessor, [RFC4645]. >=20 > Specific contributions to this memo were made by John Cowan, Mark > Davis, Martin Duerst, Frank Ellermann, Kent Karlsson, and Addison > Phillips. >=20 > This document was written with the xml2rfc tool described in > [RFC2629]. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 914] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > Author's Address >=20 > Doug Ewell (editor) > Consultant >=20 > Email: dewell@adelphia.net > URI: http://users.adelphia.net/~dewell >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 915] > =0C>=20 > Internet-Draft Update to the Language Subtag Registry =20 > January 2007 >=20 >=20 > Full Copyright Statement >=20 > Copyright (C) The Internet Society (2007). >=20 > 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. >=20 > This document and the information contained herein are=20 > provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE=20 > 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. >=20 >=20 > Intellectual Property >=20 > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be=20 > 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. =20 > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. >=20 > 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=20 > the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR=20 > repository at > http://www.ietf.org/ipr. >=20 > 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. >=20 >=20 > Acknowledgment >=20 > Funding for the RFC Editor function is provided by the IETF > Administrative Support Activity (IASA). >=20 >=20 >=20 >=20 >=20 > Ewell Expires July 18, 2007 =20 > [Page 916] > =0C> =20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 30 12:02:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwN1-0007QV-0O; Tue, 30 Jan 2007 12:02:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwN0-0007QQ-2I for ltru@ietf.org; Tue, 30 Jan 2007 12:02:10 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwMu-0000mL-Jr for ltru@ietf.org; Tue, 30 Jan 2007 12:02:10 -0500 Received: from [10.72.72.190] (snvvpn1-10-72-72-c190.corp.yahoo.com [10.72.72.190]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l0UH1PQb091908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jan 2007 09:01:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=LkokqvqYRHZwRJosPGXNUtK4O34izCdCaJ64rrMY6W8F+r6cBSx87Tsp+S0Ou1wA Message-ID: <45BF79E4.40308@yahoo-inc.com> Date: Tue, 30 Jan 2007 09:01:24 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Debbie Garside Subject: Re: [Ltru] Submission: draft-ietf-ltru-4645bis-01 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp1.corp.yahoo.com id l0UH1PQb091908 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 3eec21359cc773323f0aab45cb0596af Cc: dewell@adelphia.net, 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Really the file should be encoded in UTF-8, eliminating this silliness. But the consensus was that this would be too incompatible. Addison Debbie Garside wrote: > Hi=20 >=20 > Have read the document in question and all looks well (other than I wou= ld > have used "has been" and "is" rather than "was" in a number of places). >=20 > However, I find the following type of record format in the Registry (fo= r > =C3=81nc=C3=A1 and other records with diacritics) totally unacceptable: >=20 > %% > Type: language > Subtag: acb > Description: Áncá > Added: 2008-01-01 > %% >=20 > I know we have had this discussion before with regard to "Norwegian > Bokmål" and "Norwegian Bokmal" and indeed the dreaded apostrophe i= n > N'Ko. Where did we get with it? I would prefer to see both and I had > thought this was agreed. There needs to be an element of human readabi= lity > within the Registry methinks! >=20 > Best regards >=20 > Debbie >=20 >> -----Original Message----- >> From: Doug Ewell [mailto:dewell@adelphia.net]=20 >> Sent: 15 January 2007 02:38 >> To: LTRU Working Group >> Subject: [Ltru] Submission: draft-ietf-ltru-4645bis-01 >> >> I've just submitted draft-ietf-ltru-4645bis-01 to=20 >> Internet-Drafts@ietf.org. >> >> Because this draft is over 802,000 bytes and 916 pages long=20 >> -- longer than the previous draft because of the inclusion of=20 >> about 1,400 inverted/uninverted pairs -- I was once again=20 >> disinclined to post it to the mailing list. Instead, I've=20 >> attached a reduced version that includes all of the prose,=20 >> but omits most of the proposed new Registry contents. You=20 >> can view or download the complete draft at one of the=20 >> following locations: >> >> http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.html >> (739,857 bytes) >> http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.html.zip >> (97,302 bytes) >> http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.txt >> (857,083 bytes) >> http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.txt.zip >> (101,713 bytes) >> >> Of course, once the draft is officially posted to the IETF=20 >> site, you can get it there as well. >> >> -- >> Doug Ewell * Fullerton, California, USA * RFC 4645 * =20 >> UTN #14 http://users.adelphia.net/~dewell/ >> http://www1.ietf.org/html.charters/ltru-charter.html >> http://www.alvestrand.no/mailman/listinfo/ietf-languages >> >> >> -----8<-----cut here-----8<-----cut here-----8<-----cut=20 >> here-----8<----- >> >> >> Network Working Group D.=20 >> Ewell, Ed. >> Internet-Draft =20 >> Consultant >> Intended status: Informational =20 >> January 14, 2007 >> Expires: July 18, 2007 >> >> >> Update to the Language Subtag Registry >> draft-ietf-ltru-4645bis-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=20 >> six months >> and may be updated, replaced, or obsoleted by other=20 >> 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 July 18, 2007. >> >> Copyright Notice >> >> Copyright (C) The Internet Society (2007). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 1] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> Abstract >> >> This memo defines the procedure used to update the IANA Language >> Subtag Registry in conjunction with the publication of RFC 4646bis >> [RFC EDITOR NOTE: replace with actual RFC number], for use=20 >> in forming >> tags for the identification of languages. As an Internet-Draft, it >> also contained a complete replacement of the contents of=20 >> the Registry >> to be used by IANA in updating it. To prevent confusion, this >> material was removed before publication. >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . .=20 >> . . . . 3 >> 2. Updating the Registry . . . . . . . . . . . . . . . .=20 >> . . . . 4 >> 2.1. Starting Point . . . . . . . . . . . . . . . . .=20 >> . . . . 4 >> 2.2. New Subtags . . . . . . . . . . . . . . . . . . .=20 >> . . . . 5 >> 2.3. Modified Subtags . . . . . . . . . . . . . . . .=20 >> . . . . 5 >> 2.4. Grandfathered and Redundant Tags . . . . . . . .=20 >> . . . . 6 >> 2.5. Additional Changes . . . . . . . . . . . . . . .=20 >> . . . . 9 >> 3. Updated Registry Contents . . . . . . . . . . . . . .=20 >> . . . . 10 >> 4. Security Considerations . . . . . . . . . . . . . . .=20 >> . . . . 909 >> 5. IANA Considerations . . . . . . . . . . . . . . . . .=20 >> . . . . 910 >> 6. Changes . . . . . . . . . . . . . . . . . . . . . . .=20 >> . . . . 911 >> 7. References . . . . . . . . . . . . . . . . . . . . .=20 >> . . . . 912 >> 7.1. Normative References . . . . . . . . . . . . . .=20 >> . . . . 912 >> 7.2. Informative References . . . . . . . . . . . . .=20 >> . . . . 912 >> Appendix A. Acknowledgements . . . . . . . . . . . . . .=20 >> . . . . 914 >> Author's Address . . . . . . . . . . . . . . . . . . . .=20 >> . . . . 915 >> Intellectual Property and Copyright Statements . . . . .=20 >> . . . . 916 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 2] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> 1. Introduction >> >> [RFC4646] provided for a Language Subtag Registry and described its >> format. The initial contents of the Registry and rules for >> determining them were specified in [RFC4645]. >> >> [draft-ietf-ltru-4646bis-02] expands on [RFC4646] by adding support >> for approximately 7,200 primary and extended language subtags based >> on [ISO639-3] alpha-3 code elements. This memo describes=20 >> the process >> of updating the Registry to include these additional=20 >> subtags, and to >> make secondary changes to the Registry that result from adding the >> new subtags. >> >> In its initial phase as an Internet-Draft, this memo also=20 >> contained a >> complete replacement of the contents of the Language=20 >> Subtag Registry >> to be used by the Internet Assigned Numbers Authority (IANA) in >> updating it. This content was deleted from this memo prior to >> publication as an RFC. >> >> The format of the Language Subtag Registry, and the definition and >> intended purpose of each of the fields, are described in >> [draft-ietf-ltru-4646bis-02]. >> >> 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 >> [draft-ietf-ltru-4646bis-02]. In its Internet-Draft=20 >> phase, this memo >> did not define the permanent contents of the Registry and=20 >> should not >> be represented as doing so. >> >> Many of the subtags defined in the Language Subtag=20 >> Registry are based >> on code elements defined in [ISO639-1], [ISO639-2], [ISO639-3], >> [ISO3166-1], [ISO15924], and [UN_M.49]. The Registry is=20 >> not a mirror >> of the code lists defined by these standards and should not be used >> as one. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 3] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> 2. Updating the Registry >> >> This section describes the process for determining the updated >> contents of the Language Subtag Registry. >> >> 2.1. Starting Point >> >> The version of the Language Subtag Registry that was current at the >> time of IESG approval of this memo served as the starting point for >> this update. The process of creating that version was described in >> [RFC4645]. >> >> The source data for [ISO639-3] used for this update consisted of >> three files, available from the official site of the ISO 639-3 >> Registration Authority. [RFC EDITOR NOTE: these files are expected >> to be updated before approval of this memo.] >> >> o [iso-fdis-639-3_20061114] is a list of all language=20 >> code elements >> in [ISO639-3], including the alpha-3 code element and reference >> name for each code element. For example, the entry for the Dari >> language contained the code element "prs" and the name "Dari" >> (among other information). >> >> o [iso-fdis-639-3_Name_Index_20061114] is a list containing all >> names associated with each language according to [ISO639-3], >> including both inverted and uninverted forms where=20 >> appropriate. A >> code element may have more than one entry in this file; the >> reference name and its inverted form are usually, but=20 >> not always, >> given in the first entry. For example, this file contained an >> entry for the code element "prs" with the name "Dari"=20 >> (twice) and >> another entry with the names "Eastern Farsi" and=20 >> "Farsi, Eastern". >> >> o [iso-fdis-639-3-macrolanguages_20061114] is a list of=20 >> all alpha-3 >> code elements for languages that are encompassed by a >> macrolanguage in [ISO639-3], together with the alpha-3 code >> element for the macrolanguage. For example, a line=20 >> containing the >> code elements "fas" and "prs" indicated that the macrolanguage >> "Persian" encompasses the individual language "Dari". =20 >> (Note that >> these alpha-3 code elements may not have corresponded=20 >> directly to >> subtags in the Registry, which uses 2-letter subtags=20 >> derived from >> [ISO639-1] when possible.) >> >> The value of the File-Date field and of the Added date for each new >> subtag record are set to a date near the date of IESG approval of >> this memo. [RFC EDITOR NOTE: these dates would be updated during >> AUTH48.] >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 4] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> 2.2. New Subtags >> >> For each language in [ISO639-3] that was not already=20 >> represented by a >> primary language subtag in the Language Subtag Registry, a=20 >> new subtag >> was added to the Registry, using the [ISO639-3] code element as the >> value for the Subtag field and each of the [ISO639-3] names as a >> separate Description field. The [ISO639-3] reference name was >> represented by the first Description field. The following=20 >> rules were >> used to determine whether to add a primary or extended language >> subtag: >> >> o If the language was encompassed by a macrolanguage, as=20 >> determined >> by [iso-fdis-639-3-macrolanguages_20061114], an=20 >> extended language >> subtag was added, with the primary language subtag of the >> macrolanguage as the value for the Prefix field. >> >> o If the name of the language included the words "Sign=20 >> Language", an >> extended language subtag was added, with the string "sgn" as the >> value for the Prefix field. This is a special case that treats >> the existing primary language subtag for "Sign=20 >> Languages" as if it >> were a macrolanguage encompassing all sign languages. =20 >> (Note that >> "sgn" is defined as a "collection code" by [ISO639-3]=20 >> and hence is >> not included in that standard.) >> >> o Otherwise, a primary language subtag was added. >> >> All subtags were added to the Registry maintaining=20 >> alphabetical order >> within each type of tag: all 2-letter "language" subtags=20 >> first, then >> all 3-letter "language" subtags, and finally all all "extlang" >> subtags. Some existing records were moved to ensure this order. >> >> 2.3. Modified Subtags >> >> For each language in [ISO639-3] that was already represented by a >> primary language subtag in the Language Subtag Registry,=20 >> Description >> fields were added as necessary to reflect all names listed for that >> language (inverted and uninverted) in either >> [iso-fdis-639-3_20061114] or [iso-fdis-639-3_Name_Index_20061114]. >> The order of Description fields was adjusted to ensure that the >> reference name from [ISO639-3] was listed first, followed by other >> names from [ISO639-3] in the order presented by that standard, >> followed by any other names already existing in the Registry. In >> some cases this resulted in a reordering of Description fields for >> existing entries, even when no new values were added. >> >> No existing Description fields were changed or deleted, with the >> following exceptions: >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 5] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> o For the primary language subtag "es", the Description=20 >> "Castilian" >> was replaced by the [ISO639-3] spelling "Castillian". This was >> presumed to be an unintentional and temporary mismatch between >> [ISO639-2] and [ISO639-3]. >> >> o For similar reasons, the following spelling changes were made to >> existing Description fields in the Registry to bring=20 >> them in line >> with the corresponding names in [ISO639-3]: >> >> "gsw" changed from "Alemannic" to "Alemanic" >> >> "gwi" changed from "Gwich´in" to "Gwich'in" >> >> "nqo" changed from "N’Ko" to "N'Ko" >> >> "rup" changed from "Macedo-Romanian" to "Macedo Romanian" >> >> o The capitalization of the Subtag field for the=20 >> redundant tag "yi- >> latn" was changed to "yi-Latn" for consistency with the >> capitalization conventions described in Section 2.1 of >> [draft-ietf-ltru-4646bis-02]. >> >> 2.4. Grandfathered and Redundant Tags >> >> As stated in [draft-ietf-ltru-4646bis-02], "grandfathered" and >> "redundant" tags are complete tags in the Language Subtag Registry >> that were registered under [RFC1766] or [RFC3066] and remain valid. >> Grandfathered tags cannot be generated from a valid combination of >> subtags, while "redundant" tags can be. >> >> Under certain conditions, registration of a subtag under >> [draft-ietf-ltru-4646bis-02] may cause a grandfathered tag to be >> reclassified as redundant. It may also enable the creation of a >> generative tag with the same meaning as a grandfathered or=20 >> redundant >> tag; in that case, the grandfathered or redundant tag is marked as >> Deprecated, and the generative tag (including the new=20 >> subtag) becomes >> its Preferred-Value. >> >> As a result of adding the new subtags in this update, the following >> grandfathered tags became composable and were reclassified as >> redundant: >> >> zh-cmn >> >> zh-cmn-Hans >> >> zh-cmn-Hant >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 6] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> zh-gan >> >> zh-wuu >> >> zh-yue >> >> The following grandfathered tags were deprecated, with the=20 >> indicated >> generative tag serving as the Preferred-Value: >> >> i-ami (Preferred-Value: ami) >> >> i-bnn (Preferred-Value: bnn) >> >> i-pwn (Preferred-Value: pwn) >> >> i-tao (Preferred-Value: tao) >> >> i-tay (Preferred-Value: tay) >> >> i-tsu (Preferred-Value: tsu) >> >> sgn-CH-de (Preferred-Value: sgn-sgg) >> >> zh-hakka (Preferred-Value: zh-hak) >> >> zh-min (no Preferred-Value; see below) >> >> zh-min-nan (Preferred-Value: zh-nan) >> >> zh-xiang (Preferred-Value: zh-hns) >> >> The tag "zh-min", originally registered under [RFC1766],=20 >> is a special >> case: it represents a small class of languages, but is not a true >> macrolanguage. It could not ever become a generative tag since the >> [ISO639-3] code element "min" is assigned to an individual language >> (Minangkabau) that is not related to Chinese ("zh"). Because it is >> not believed to represent a useful linguistic entity for tagging >> purposes, it was deprecated without a Preferred-Value. >> >> The following redundant sign-language tags were=20 >> deprecated, with the >> indicated generative tag serving as the Preferred-Value: >> >> sgn-BR (Preferred-Value: sgn-bzs) >> >> sgn-CO (Preferred-Value: sgn-csn) >> >> sgn-DE (Preferred-Value: sgn-gsg) >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 7] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> sgn-DK (Preferred-Value: sgn-dsl) >> >> sgn-ES (Preferred-Value: sgn-ssp) >> >> sgn-FR (Preferred-Value: sgn-fsl) >> >> sgn-GB (Preferred-Value: sgn-bfi) >> >> sgn-GR (Preferred-Value: sgn-gss) >> >> sgn-IE (Preferred-Value: sgn-isg) >> >> sgn-IT (Preferred-Value: sgn-ise) >> >> sgn-JP (Preferred-Value: sgn-jsl) >> >> sgn-MX (Preferred-Value: sgn-mfs) >> >> sgn-NI (Preferred-Value: sgn-ncs) >> >> sgn-NL (Preferred-Value: sgn-dse) >> >> sgn-NO (Preferred-Value: sgn-nsl) >> >> sgn-PT (Preferred-Value: sgn-psr) >> >> sgn-SE (Preferred-Value: sgn-swl) >> >> sgn-US (Preferred-Value: sgn-ase) >> >> sgn-ZA (Preferred-Value: sgn-sfs) >> >> No change was made to the Description field(s) for any of the >> grandfathered or redundant tags. For example, the redundant tag >> "sgn-US" continues to carry the Description "American Sign=20 >> Language". >> The sign language tags registered prior to [RFC4646] remain an >> exception to the general principle that the meaning of a non- >> grandfathered tag can be derived from its component subtags. >> >> In previous versions of the Registry, grandfathered tags that had >> been deprecated as a result of adding an ISO 639-based language >> subtag included a Comments field, with a value of the form=20 >> "replaced >> by ISO code xxx", where "xxx" represented the new language subtag. >> These comments duplicated the information contained within the >> Preferred-Value field, and were deleted as part of this update. No >> changes were made to other Comments fields. >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 8] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> 2.5. Additional Changes >> >> For consistency with the handling of alternative names in language >> subtags, Description fields for script subtags taken from=20 >> [ISO15924] >> that represent alternative names were converted to multiple >> Description fields. For example, the Description "Han=20 >> (Hanzi, Kanji, >> Hanja)" was converted to four separate Description fields. Some >> Description fields for script subtags contained parenthetical >> material that was explanatory, rather than identifying alternative >> names; these fields were not altered. >> >> The situation does not apply to region subtags taken from=20 >> [ISO3166-1] >> and [UN_M.49] because those standards do not provide=20 >> freely available >> alternative names for code elements. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 9] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> 3. Updated Registry Contents >> >> The remainder of this section specified the updated set of records >> for the Language Subtag Registry. This material was deleted before >> publication of this memo, to avoid any potential confusion with the >> Registry itself. The IANA Language Subtag Registry can be found at >> under "Language Tags". >> >> [RFC EDITOR NOTE: the remainder of this section is to be=20 >> deleted upon >> publication.] >> >> The updated contents of the Language Subtag Registry follow. This >> data is intended as a complete replacement for the current contents >> of the Registry. The Registry begins with the line that=20 >> 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: 2008-01-01 >> %% >> Type: language >> Subtag: aa >> Description: Afar >> Added: 2005-10-16 >> %% >> Type: language >> Subtag: ab >> Description: Abkhazian >> Added: 2005-10-16 >> Suppress-Script: Cyrl >> %% >> Type: language >> Subtag: ae >> Description: Avestan >> Added: 2005-10-16 >> %% >> Type: language >> Subtag: af >> Description: Afrikaans >> Added: 2005-10-16 >> Suppress-Script: Latn >> %% >> Type: language >> Subtag: ak >> Description: Akan >> Added: 2005-10-16 >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 10] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> Description: Cantonese >> Added: 1999-12-18 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 908] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> 4. Security Considerations >> >> For security considerations relevant to the Language=20 >> Subtag Registry >> and the use of language tags, see [draft-ietf-ltru-4646bis-02]. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 909] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> 5. IANA Considerations >> >> In its initial phase as an Internet-Draft, this memo contained a >> complete replacement of the contents of the Language=20 >> Subtag Registry >> to be used by IANA in updating it. As an RFC, it contains=20 >> a pointer >> to the Registry, which is maintained by IANA. The Language Subtag >> Registry can be found at under >> "Language Tags". For details on the procedures for the format and >> ongoing maintenance of this Registry, see >> [draft-ietf-ltru-4646bis-02]. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 910] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> 6. Changes >> >> [Editor's Note: This section is provided for the convenience of >> reviewers and will be removed from the final document.] >> >> This memo is a new work, not an incremental update. The procedure >> for populating the original Language Subtag Registry, specified by >> the earlier [RFC4646], is included by reference to [RFC4645]. >> Therefore, no changes from [RFC4645] are listed in this section. >> >> Changes between draft-ietf-ltru-4645bis-00 and this version are: >> >> o Changed procedure to incorporate data from new "Language Names >> Index" file and to ensure that the [ISO639-3] reference name is >> the first Description field. >> >> o Removed some exceptions as a result of improved [ISO639-3] draft >> data. >> >> o Removed section dealing with special handling of "(generic)" and >> "(specific)" strings within language names. >> >> o Added an explanation of the process of converting a compound >> Description field for a script subtag to multiple Description >> fields. >> >> o Removed Comments fields of the form "replaced by ISO code xxx", >> which provided no additional information beyond the Preferred- >> Value field. >> >> o Clarified that the included Registry contents are a complete >> replacement for the existing Registry, not a set of deltas. (J. >> Cowan) >> >> o Changed "included within" a macrolanguage to use=20 >> "encompassed by" >> throughout. (J. Cowan) >> >> o Provided better explanation for deprecation of "zh-min" in >> Section 2.4. (J. Cowan) >> >> o Added Changes and Acknowledgements sections. >> >> >> >> >> >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 911] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> 7. References >> >> 7.1. Normative References >> >> [ISO639-3] >> International Organization for Standardization,=20 >> "ISO/FDIS >> 639-3:2007. Codes for the representation of names of >> languages -- Part 3: Alpha-3 code for comprehensive >> coverage of languages, first edition", 2007. >> >> [draft-ietf-ltru-4646bis-02] >> Phillips, A., Ed. and M. Davis, Ed., "Tags for=20 >> Identifying >> Languages", December 2006, > ID/draft-ietf-ltru-4646bis-02.html>. >> >> [iso-fdis-639-3-macrolanguages_20061114] >> International Organization for Standardization,=20 >> "ISO/FDIS >> 639-3 Macrolanguage Mappings", November 2006, > www.sil.org/iso639-3/ >> iso-fdis-639-3-macrolanguages_20061114.tab>. >> >> [iso-fdis-639-3_20061114] >> International Organization for Standardization,=20 >> "ISO/FDIS >> 639-3 Code Set", November 2006, >> =20 >> . >> >> [iso-fdis-639-3_Name_Index_20061114] >> International Organization for Standardization,=20 >> "ISO/FDIS >> 639-3 Language Names Index", November 2006, > www.sil.org/iso639-3/ >> iso-fdis-639-3_Name_Index_20061114.tab>. >> >> 7.2. Informative References >> >> [ISO15924] >> International Organization for Standardization, "ISO >> 15924:2004. Information and documentation -- Codes for >> the representation of names of scripts", January 2004. >> >> [ISO3166-1] >> International Organization for Standardization,=20 >> "ISO 3166: >> 1988. Codes for the representation of names of=20 >> countries, >> 3rd edition", August 1988. >> >> [ISO639-1] >> International Organization for Standardization,=20 >> "ISO 639- >> 1:2002. Codes for the representation of names of >> languages -- Part 1: Alpha-2 code", 2002. >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 912] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> [ISO639-2] >> International Organization for Standardization,=20 >> "ISO 639- >> 2:1998. Codes for the representation of names of >> languages -- Part 2: Alpha-3 code, first edition", 1998. >> >> [RFC1766] Alvestrand, H., "Tags for the Identification of >> Languages", RFC 1766, March 1995. >> >> [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, >> June 1999. >> >> [RFC3066] Alvestrand, H., "Tags for the Identification of >> Languages", RFC 3066, January 2001. >> >> [RFC4645] Ewell, D., "Initial Language Subtag Registry", RFC 4645, >> September 2006. >> >> [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying >> Languages", BCP 47, RFC 4646, September 2006. >> >> [UN_M.49] Statistics Division, United Nations, "Standard=20 >> Country or >> Area Codes for Statistical Use", UN Standard Country or >> Area Codes for Statistical Use, Revision 4=20 >> (United Nations >> publication, Sales No. 98.XVII.9), June 1999. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 913] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> Appendix A. Acknowledgements >> >> This memo is a collaborative work of the Language Tag=20 >> Registry Update >> (LTRU) Working Group. All of its members have made significant >> contributions to this memo and to its predecessor, [RFC4645]. >> >> Specific contributions to this memo were made by John Cowan, Mark >> Davis, Martin Duerst, Frank Ellermann, Kent Karlsson, and Addison >> Phillips. >> >> This document was written with the xml2rfc tool described in >> [RFC2629]. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 914] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> Author's Address >> >> Doug Ewell (editor) >> Consultant >> >> Email: dewell@adelphia.net >> URI: http://users.adelphia.net/~dewell >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 915] >> =0C>=20 >> Internet-Draft Update to the Language Subtag Registry =20 >> January 2007 >> >> >> Full Copyright Statement >> >> Copyright (C) The Internet Society (2007). >> >> 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. >> >> This document and the information contained herein are=20 >> provided on an >> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE=20 >> 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. >> >> >> Intellectual Property >> >> The IETF takes no position regarding the validity or scope of any >> Intellectual Property Rights or other rights that might be=20 >> 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. =20 >> 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=20 >> the use of >> such proprietary rights by implementers or users of this >> specification can be obtained from the IETF on-line IPR=20 >> 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. >> >> >> Acknowledgment >> >> Funding for the RFC Editor function is provided by the IETF >> Administrative Support Activity (IASA). >> >> >> >> >> >> Ewell Expires July 18, 2007 =20 >> [Page 916] >> =0C> =20 >> >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> >> >> >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru --=20 Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 30 14:13:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByQM-0007wQ-Mv; Tue, 30 Jan 2007 14:13:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByQM-0007wK-3D for ltru@lists.ietf.org; Tue, 30 Jan 2007 14:13:46 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HByQK-0006hf-PA for ltru@lists.ietf.org; Tue, 30 Jan 2007 14:13:46 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HByQ8-0002sX-LC for ltru@lists.ietf.org; Tue, 30 Jan 2007 20:13:32 +0100 Received: from d255181.dialin.hansenet.de ([80.171.255.181]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Jan 2007 20:13:32 +0100 Received: from nobody by d255181.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Jan 2007 20:13:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 30 Jan 2007 20:12:25 +0100 Organization: Lines: 23 Message-ID: <45BF9899.6C24@xyzzy.claranet.de> References: <010801c7384e$32d14ad0$6601a8c0@DGBP7M81> 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: d255181.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > There needs to be an element of human readability within the Registry > methinks! It's perfectly readable on any device supporting ASCII. Unofficial XML conversions are at the usual places. If you've extracted the registry, removing the page breaks etc., you could also transform it into simple HTML by adding a line... whatever you like </title<pre> ...at the begin, and a line... </pre> ...at the end. Any browser supporting hex. NCRs and the fonts required for the encoded non-ASCII characters would then display it. Fortunately there are no offending "<" characters in the proposed registry. Should we demand to encode "<" and ">" as hex. NCRs ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 30 14:38:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByo8-0002Vm-Oo; Tue, 30 Jan 2007 14:38:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByo7-0002Rw-E9 for ltru@lists.ietf.org; Tue, 30 Jan 2007 14:38:19 -0500 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HByo6-0004J2-59 for ltru@lists.ietf.org; Tue, 30 Jan 2007 14:38:19 -0500 Received: by wx-out-0506.google.com with SMTP id h31so2105695wxd for <ltru@lists.ietf.org>; Tue, 30 Jan 2007 11:38:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=hRMVfJLk7VJWAaTcMggxVGRd3WDMthW7hAd04nYd6rXYUnY2QSi8RGcr+edv/PEb645Bclp4tqMmp5HiIF0nLHW7ZUx2uw02J38MnvFgaodNDVCHdxbEOuqMwA8j7Jxz1UU04VsDUtIaGHbYwDuzkxLyAGolIoX1bJPDEOJmbjo= Received: by 10.90.115.4 with SMTP id n4mr9053012agc.1170185887342; Tue, 30 Jan 2007 11:38:07 -0800 (PST) Received: by 10.90.50.20 with HTTP; Tue, 30 Jan 2007 11:37:52 -0800 (PST) Message-ID: <30b660a20701301137j6f55ce96y217dfbb51d01ec12@mail.gmail.com> Date: Tue, 30 Jan 2007 11:37:52 -0800 From: "Mark Davis" <mark.davis@icu-project.org> To: "Frank Ellermann" <nobody@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-01 In-Reply-To: <45BF9899.6C24@xyzzy.claranet.de> MIME-Version: 1.0 References: <010801c7384e$32d14ad0$6601a8c0@DGBP7M81> <E1HBvRS-0004Ww-QA@megatron.ietf.org> <45BF9899.6C24@xyzzy.claranet.de> X-Google-Sender-Auth: 1de17d0e475dc5e7 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ltru> List-Post: <mailto:ltru@ietf.org> List-Help: <mailto:ltru-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1656020376==" Errors-To: ltru-bounces@ietf.org --===============1656020376== Content-Type: multipart/alternative; boundary="----=_Part_3043_1340316.1170185872062" ------=_Part_3043_1340316.1170185872062 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline not a bad idea. On 1/30/07, Frank Ellermann <nobody@xyzzy.claranet.de> wrote: > > Debbie Garside wrote: > > > There needs to be an element of human readability within the Registry > > methinks! > > It's perfectly readable on any device supporting ASCII. Unofficial XML > conversions are at the usual places. If you've extracted the registry, > removing the page breaks etc., you could also transform it into simple > HTML by adding a line... > > <title> whatever you like </title<pre> > > ...at the begin, and a line... > > </pre> > > ...at the end. Any browser supporting hex. NCRs and the fonts required > for the encoded non-ASCII characters would then display it. Fortunately > there are no offending "<" characters in the proposed registry. Should > we demand to encode "<" and ">" as hex. NCRs ? > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_3043_1340316.1170185872062 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline not a bad idea.<br><br><div><span class="gmail_quote">On 1/30/07, <b class="gmail_sendername">Frank Ellermann</b> <<a href="mailto:nobody@xyzzy.claranet.de">nobody@xyzzy.claranet.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Debbie Garside wrote:<br><br>> There needs to be an element of human readability within the Registry<br>> methinks!<br><br>It's perfectly readable on any device supporting ASCII.  Unofficial XML<br>conversions are at the usual places.  If you've extracted the registry, <br>removing the page breaks etc., you could also transform it into simple<br>HTML by adding a line...<br><br>        <title> whatever you like </title<pre><br><br>...at the begin, and a line...<br><br>        </pre> <br><br>...at the end.  Any browser supporting hex. NCRs and the fonts required<br>for the encoded non-ASCII characters would then display it.  Fortunately<br>there are no offending "<" characters in the proposed registry.  Should <br>we demand to encode "<" and ">" as hex. NCRs ?<br><br>Frank<br><br><br><br>_______________________________________________<br>Ltru mailing list<br><a href="mailto:Ltru@ietf.org">Ltru@ietf.org </a><br><a href="https://www1.ietf.org/mailman/listinfo/ltru">https://www1.ietf.org/mailman/listinfo/ltru</a><br></blockquote></div><br><br clear="all"><br>-- <br>Mark ------=_Part_3043_1340316.1170185872062-- --===============1656020376== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1656020376==-- From ltru-bounces@ietf.org Tue Jan 30 16:14:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC0Iu-0002Bz-0d; Tue, 30 Jan 2007 16:14:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC0Ir-0002Bm-UK for ltru@lists.ietf.org; Tue, 30 Jan 2007 16:14:09 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC0Iq-0003Mu-H4 for ltru@lists.ietf.org; Tue, 30 Jan 2007 16:14:09 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l0ULDtmp017970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jan 2007 13:13:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=2Pchd84ep7qqg3ZPctoktrISMbZ3EENZiChjAz3jmDwYq1yDw8sRecGizPFlyU53 Message-ID: <45BFB513.2000409@yahoo-inc.com> Date: Tue, 30 Jan 2007 13:13:55 -0800 From: Addison Phillips <addison@yahoo-inc.com> User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Mark Davis <mark.davis@icu-project.org> Subject: Re: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-01 References: <010801c7384e$32d14ad0$6601a8c0@DGBP7M81> <E1HBvRS-0004Ww-QA@megatron.ietf.org> <45BF9899.6C24@xyzzy.claranet.de> <30b660a20701301137j6f55ce96y217dfbb51d01ec12@mail.gmail.com> In-Reply-To: <30b660a20701301137j6f55ce96y217dfbb51d01ec12@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Frank Ellermann <nobody@xyzzy.claranet.de>, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ltru> List-Post: <mailto:ltru@ietf.org> List-Help: <mailto:ltru-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe> Errors-To: ltru-bounces@ietf.org Nah. That's a problem for conversions to/from XML. Besides, we don't have any examples of the problem to deal with. Addison Mark Davis wrote: > not a bad idea. > > On 1/30/07, Frank Ellermann <nobody@xyzzy.claranet.de> wrote: >> >> Debbie Garside wrote: >> >> > There needs to be an element of human readability within the Registry >> > methinks! >> >> It's perfectly readable on any device supporting ASCII. Unofficial XML >> conversions are at the usual places. If you've extracted the registry, >> removing the page breaks etc., you could also transform it into simple >> HTML by adding a line... >> >> <title> whatever you like </title<pre> >> >> ...at the begin, and a line... >> >> </pre> >> >> ...at the end. Any browser supporting hex. NCRs and the fonts required >> for the encoded non-ASCII characters would then display it. Fortunately >> there are no offending "<" characters in the proposed registry. Should >> we demand to encode "<" and ">" as hex. NCRs ? >> >> Frank >> >> >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jan 30 19:55:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3kd-0001RP-Rn; Tue, 30 Jan 2007 19:55:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3kc-0001R6-Qe for ltru@lists.ietf.org; Tue, 30 Jan 2007 19:55:02 -0500 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC3kb-0004JX-Fk for ltru@lists.ietf.org; Tue, 30 Jan 2007 19:55:02 -0500 Received: by wr-out-0506.google.com with SMTP id i22so44514wra for <ltru@lists.ietf.org>; Tue, 30 Jan 2007 16:55:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=hC+vhK3OL+2GT01VO4qNlBEqfLS8iecwYU0KDykE4SIfTgr1f4j3810SOg//kaC+C4jjRRlDDVpCcVdQVuCimoaZRj/pn7aMQrGhzDieUet+XESLpI1YJtlQTr9LUzXuYUNVV/9soehMS22phu495v987cDbhnv/ntDyMkfGh1o= Received: by 10.90.118.12 with SMTP id q12mr206507agc.1170204901264; Tue, 30 Jan 2007 16:55:01 -0800 (PST) Received: by 10.90.50.20 with HTTP; Tue, 30 Jan 2007 16:55:01 -0800 (PST) Message-ID: <30b660a20701301655w6b230b1ci8f1a055a1b0b7272@mail.gmail.com> Date: Tue, 30 Jan 2007 16:55:01 -0800 From: "Mark Davis" <mark.davis@icu-project.org> To: "Addison Phillips" <addison@yahoo-inc.com> Subject: Re: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-01 In-Reply-To: <45BFB513.2000409@yahoo-inc.com> MIME-Version: 1.0 References: <010801c7384e$32d14ad0$6601a8c0@DGBP7M81> <E1HBvRS-0004Ww-QA@megatron.ietf.org> <45BF9899.6C24@xyzzy.claranet.de> <30b660a20701301137j6f55ce96y217dfbb51d01ec12@mail.gmail.com> <45BFB513.2000409@yahoo-inc.com> X-Google-Sender-Auth: 663af1b4ded07e63 X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Frank Ellermann <nobody@xyzzy.claranet.de>, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ltru> List-Post: <mailto:ltru@ietf.org> List-Help: <mailto:ltru-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0949255463==" Errors-To: ltru-bounces@ietf.org --===============0949255463== Content-Type: multipart/alternative; boundary="----=_Part_14268_29560621.1170204901205" ------=_Part_14268_29560621.1170204901205 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline But it doesn't hurt any to guarantee that there are no characters that would cause problems. On 1/30/07, Addison Phillips <addison@yahoo-inc.com> wrote: > > Nah. That's a problem for conversions to/from XML. Besides, we don't > have any examples of the problem to deal with. > > Addison > > Mark Davis wrote: > > not a bad idea. > > > > On 1/30/07, Frank Ellermann <nobody@xyzzy.claranet.de> wrote: > >> > >> Debbie Garside wrote: > >> > >> > There needs to be an element of human readability within the Registry > >> > methinks! > >> > >> It's perfectly readable on any device supporting ASCII. Unofficial XML > >> conversions are at the usual places. If you've extracted the registry, > >> removing the page breaks etc., you could also transform it into simple > >> HTML by adding a line... > >> > >> <title> whatever you like </title<pre> > >> > >> ...at the begin, and a line... > >> > >> </pre> > >> > >> ...at the end. Any browser supporting hex. NCRs and the fonts required > >> for the encoded non-ASCII characters would then display > it. Fortunately > >> there are no offending "<" characters in the proposed registry. Should > >> we demand to encode "<" and ">" as hex. NCRs ? > >> > >> Frank > >> > >> > >> > >> _______________________________________________ > >> Ltru mailing list > >> Ltru@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ltru > >> > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > -- Mark ------=_Part_14268_29560621.1170204901205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline But it doesn't hurt any to guarantee that there are no characters that would cause problems.<br><br><div><span class="gmail_quote">On 1/30/07, <b class="gmail_sendername">Addison Phillips</b> <<a href="mailto:addison@yahoo-inc.com"> addison@yahoo-inc.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Nah. That's a problem for conversions to/from XML. Besides, we don't <br>have any examples of the problem to deal with.<br><br>Addison<br><br>Mark Davis wrote:<br>> not a bad idea.<br>><br>> On 1/30/07, Frank Ellermann <<a href="mailto:nobody@xyzzy.claranet.de">nobody@xyzzy.claranet.de </a>> wrote:<br>>><br>>> Debbie Garside wrote:<br>>><br>>> > There needs to be an element of human readability within the Registry<br>>> > methinks!<br>>><br>>> It's perfectly readable on any device supporting ASCII.  Unofficial XML <br>>> conversions are at the usual places.  If you've extracted the registry,<br>>> removing the page breaks etc., you could also transform it into simple<br>>> HTML by adding a line...<br>>><br> >>         <title> whatever you like </title<pre><br>>><br>>> ...at the begin, and a line...<br>>><br>>>         </pre><br>>><br>>> ...at the end.  Any browser supporting hex. NCRs and the fonts required <br>>> for the encoded non-ASCII characters would then display it.  Fortunately<br>>> there are no offending "<" characters in the proposed registry.  Should<br>>> we demand to encode "<" and ">" as hex. NCRs ? <br>>><br>>> Frank<br>>><br>>><br>>><br>>> _______________________________________________<br>>> Ltru mailing list<br>>> <a href="mailto:Ltru@ietf.org">Ltru@ietf.org</a><br> >> <a href="https://www1.ietf.org/mailman/listinfo/ltru">https://www1.ietf.org/mailman/listinfo/ltru</a><br>>><br>><br>><br>><br>><br>> ------------------------------------------------------------------------ <br>><br>> _______________________________________________<br>> Ltru mailing list<br>> <a href="mailto:Ltru@ietf.org">Ltru@ietf.org</a><br>> <a href="https://www1.ietf.org/mailman/listinfo/ltru">https://www1.ietf.org/mailman/listinfo/ltru </a><br><br>--<br>Addison Phillips<br>Globalization Architect -- Yahoo! Inc.<br><br>Internationalization is an architecture.<br>It is not a feature.<br></blockquote></div><br><br clear="all"><br>-- <br>Mark ------=_Part_14268_29560621.1170204901205-- --===============0949255463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0949255463==-- From ltru-bounces@ietf.org Tue Jan 30 20:18:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC47P-000526-HH; Tue, 30 Jan 2007 20:18:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC47O-000521-AR for ltru@lists.ietf.org; Tue, 30 Jan 2007 20:18:34 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC47L-0004l9-Te for ltru@lists.ietf.org; Tue, 30 Jan 2007 20:18:34 -0500 Received: from [10.72.76.84] (snvvpn2-10-72-76-c84.corp.yahoo.com [10.72.76.84]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l0V1I9UB034707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jan 2007 17:18:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=eIQipIXeETvryjBQuSPxTDJ8/POMm4wTw4iyy+G5FvfFD40OOaGIqNa80NTlGWXr Message-ID: <45BFEE50.8010308@yahoo-inc.com> Date: Tue, 30 Jan 2007 17:18:08 -0800 From: Addison Phillips <addison@yahoo-inc.com> User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Mark Davis <mark.davis@icu-project.org> Subject: Re: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-01 References: <010801c7384e$32d14ad0$6601a8c0@DGBP7M81> <E1HBvRS-0004Ww-QA@megatron.ietf.org> <45BF9899.6C24@xyzzy.claranet.de> <30b660a20701301137j6f55ce96y217dfbb51d01ec12@mail.gmail.com> <45BFB513.2000409@yahoo-inc.com> <30b660a20701301655w6b230b1ci8f1a055a1b0b7272@mail.gmail.com> In-Reply-To: <30b660a20701301655w6b230b1ci8f1a055a1b0b7272@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Frank Ellermann <nobody@xyzzy.claranet.de>, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ltru> List-Post: <mailto:ltru@ietf.org> List-Help: <mailto:ltru-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe> Errors-To: ltru-bounces@ietf.org You mean like ampersand? We could get carried away here with additional escape fun. I'm not wild about changing anything we don't need to: this we don't need to change. The characters in question are a quirk of the *target* format and have nothing to do with the record-jar format. Caveat convertor. Addison Mark Davis wrote: > But it doesn't hurt any to guarantee that there are no characters that > would > cause problems. > > On 1/30/07, Addison Phillips <addison@yahoo-inc.com> wrote: >> >> Nah. That's a problem for conversions to/from XML. Besides, we don't >> have any examples of the problem to deal with. >> >> Addison >> >> Mark Davis wrote: >> > not a bad idea. >> > >> > On 1/30/07, Frank Ellermann <nobody@xyzzy.claranet.de> wrote: >> >> >> >> Debbie Garside wrote: >> >> >> >> > There needs to be an element of human readability within the >> Registry >> >> > methinks! >> >> >> >> It's perfectly readable on any device supporting ASCII. Unofficial >> XML >> >> conversions are at the usual places. If you've extracted the >> registry, >> >> removing the page breaks etc., you could also transform it into simple >> >> HTML by adding a line... >> >> >> >> <title> whatever you like </title<pre> >> >> >> >> ...at the begin, and a line... >> >> >> >> </pre> >> >> >> >> ...at the end. Any browser supporting hex. NCRs and the fonts >> required >> >> for the encoded non-ASCII characters would then display >> it. Fortunately >> >> there are no offending "<" characters in the proposed registry. >> Should >> >> we demand to encode "<" and ">" as hex. NCRs ? >> >> >> >> Frank >> >> >> >> >> >> >> >> _______________________________________________ >> >> Ltru mailing list >> >> Ltru@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/ltru >> >> >> > >> > >> > >> > >> > >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Ltru mailing list >> > Ltru@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ltru >> >> -- >> Addison Phillips >> Globalization Architect -- Yahoo! Inc. >> >> Internationalization is an architecture. >> It is not a feature. >> > > > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 31 01:38:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC971-0000vW-Iv; Wed, 31 Jan 2007 01:38:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC970-0000vH-Ih for ltru@ietf.org; Wed, 31 Jan 2007 01:38:30 -0500 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC96y-0002uO-S2 for ltru@ietf.org; Wed, 31 Jan 2007 01:38:30 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070131063828.WUZE11551.mta13.adelphia.net@DGBP7M81> for <ltru@ietf.org>; Wed, 31 Jan 2007 01:38:28 -0500 Message-ID: <003f01c74502$6b349dd0$6801a8c0@DGBP7M81> From: "Doug Ewell" <dewell@adelphia.net> To: "LTRU Working Group" <ltru@ietf.org> References: <E1HBvRU-0004XN-Uv@megatron.ietf.org> Date: Tue, 30 Jan 2007 22:38:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ltru> List-Post: <mailto:ltru@ietf.org> List-Help: <mailto:ltru-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe> Errors-To: ltru-bounces@ietf.org Debbie Garside <debbie at ictmarketing dot co dot uk> wrote: > Have read the document in question and all looks well (other than I > would have used "has been" and "is" rather than "was" in a number of > places). I've probably been inconsistent in that regard, so I'd appreciate specific pointers. I should point out, though, that in an early draft version of what became RFC 4645, I wrote about how these rules "are" applied and those records "are" added to the initial Registry, and someone (I don't remember who) countered that it should be "were" since I was describing the one-off procedure by which the initial Registry was compiled. > However, I find the following type of record format in the Registry > (for Áncá and other records with diacritics) totally unacceptable: > > %% > Type: language > Subtag: acb > Description: Áncá > Added: 2008-01-01 > %% This is really a comment on draft-ietf-ltru-4646bis-02, Section 3.1.1 ("File Format"), since I insist on having RFC 4645bis follow the rules and grammar for the Registry that are laid down in RFC 4646bis. Personally I greatly prefer UTF-8, and find it hard to believe that in 2007 (or even in 2004, when I joined this project) the awkward, ugly escape sequences are somehow safer or more portable than UTF-8. But that's what we have been told, I guess by IETF. (I should note that IETF is stil unable to reach consensus on allowing UTF-8 in RFCs, partly because someone always manages to twist the issue into "allow PDF as a definitive format for RFCs so we can include beautiful, elaborate circuit diagrams.") If we are going to reopen this issue, I suggest we reopen it from the RFC 4646bis POV and let the resulting decision filter down to 4645bis. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 31 05:24:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCds-0002OT-LT; Wed, 31 Jan 2007 05:24:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCdr-0002OO-1c for ltru@ietf.org; Wed, 31 Jan 2007 05:24:39 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCCdp-0001LJ-Nb for ltru@ietf.org; Wed, 31 Jan 2007 05:24:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 3226326C156; Wed, 31 Jan 2007 11:24:18 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 174F126C0D0; Wed, 31 Jan 2007 11:24:18 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 144B358ED18; Wed, 31 Jan 2007 11:24:18 +0100 (CET) Date: Wed, 31 Jan 2007 11:24:18 +0100 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> To: Doug Ewell <dewell@adelphia.net> Message-ID: <20070131102417.GA13187@nic.fr> References: <E1HBvRU-0004XN-Uv@megatron.ietf.org> <003f01c74502$6b349dd0$6801a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003f01c74502$6b349dd0$6801a8c0@DGBP7M81> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: LTRU Working Group <ltru@ietf.org> Subject: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ltru> List-Post: <mailto:ltru@ietf.org> List-Help: <mailto:ltru-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe> Errors-To: ltru-bounces@ietf.org On Tue, Jan 30, 2007 at 10:38:28PM -0800, Doug Ewell <dewell@adelphia.net> wrote a message of 52 lines which said: > Personally I greatly prefer UTF-8, and find it hard to believe that > in 2007 (or even in 2004, when I joined this project) the awkward, > ugly escape sequences are somehow safer or more portable than UTF-8. > But that's what we have been told, I guess by IETF. I want to emphasize (as I did today on ietf-languages) that the debate is open at IETF, see Internet-Draft draft-klensin-unicode-escapes-01. Tim Bray said more or less what you say in http://www1.ietf.org/mail-archive/web/discuss/current/msg00447.html https://www1.ietf.org/mailman/listinfo/discuss if you want to participate. > (I should note that IETF is stil unable to reach consensus on > allowing UTF-8 in RFCs, partly because someone always manages to > twist the issue into "allow PDF as a definitive format for RFCs so > we can include beautiful, elaborate circuit diagrams.") AFAIK, it's a problem with the very conservative RFC editor, not with IETF. Now that the IETF has its own set of documents, the IONs, we will see if UTF-8 works. (http://www.ietf.org/IESG/content/ions/ion-ion-format.txt: "However, UTF-8 may be used") _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jan 31 09:21:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGLQ-0001l6-Lv; Wed, 31 Jan 2007 09:21:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGLP-0001kr-FQ for ltru@ietf.org; Wed, 31 Jan 2007 09:21:51 -0500 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGLN-0005rf-Hx for ltru@ietf.org; Wed, 31 Jan 2007 09:21:51 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070131142144.YYTM11551.mta13.adelphia.net@DGBP7M81>; Wed, 31 Jan 2007 09:21:44 -0500 Message-ID: <001101c74543$2359c6c0$6801a8c0@DGBP7M81> From: "Doug Ewell" <dewell@adelphia.net> To: "LTRU Working Group" <ltru@ietf.org> References: <E1HBvRU-0004XN-Uv@megatron.ietf.org> <003f01c74502$6b349dd0$6801a8c0@DGBP7M81> <20070131102417.GA13187@nic.fr> Date: Wed, 31 Jan 2007 06:21:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: Submission: draft-ietf-ltru-4645bis-01 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ltru> List-Post: <mailto:ltru@ietf.org> List-Help: <mailto:ltru-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe> Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer <bortzmeyer at nic dot fr> wrote: > I want to emphasize (as I did today on ietf-languages) that the debate > is open at IETF, see Internet-Draft draft-klensin-unicode-escapes-01. > Tim Bray said more or less what you say in > http://www1.ietf.org/mail-archive/web/discuss/current/msg00447.html The stand taken by IETF in 2005 was responsible for the decision the LTRU WG made, and wrote into in RFC 4646, and hasn't overturned yet. If the debate is now open at LTRU, then we'd better resolve it *right now*, at the RFC 4646bis level. If not, then there's no change to be made in RFC 4645bis. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru