From ltru-bounces@ietf.org Sun Jul 01 18:58:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I58Nc-0004R9-Kd; Sun, 01 Jul 2007 18:58:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I58Nc-0004R4-Ao for ltru-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 18:58:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I58Nc-0004QN-0m for ltru@ietf.org; Sun, 01 Jul 2007 18:58:56 -0400 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 1I58NX-0008Nt-GH for ltru@ietf.org; Sun, 01 Jul 2007 18:58:55 -0400 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 <20070701225850.CBOZ14967.mta16.adelphia.net@DGBP7M81>; Sun, 1 Jul 2007 18:58:50 -0400 Message-ID: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , Date: Sun, 1 Jul 2007 15:58:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: Subject: [Ltru] Solving the UTF-8 problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This is intentionally cross-posted to LTRU and ietf-languages, since it deals with both implementation policy and proposed changes to RFC 4646bis and 4645bis. CE Whitehead wrote on ietf-languages: > I want to update the 1694acad comments field to include a transliteration > into Basic Latin (also--perhaps???--to fix the inconsistency as 4eme is > missing the accent grave on the e!! : > > Comments: 17th century French, as catalogued in the "Dictionnaire de > l'académie françoise" ("l'academie francoise"), 4ème (4eme) > ed. 1694; frequently includes elements of Middle French, as this is a > transitional period. I really, really don't like the direction this is headed. Ultimately we will find ourselves having to provide duplicate Description and Comments content for every non-ASCII character in the Language Subtag Registry, removing most of the advantage of being able to represent non-ASCII in the first place. What are we going to do when the ISO 639-3 code list is finalized and we have to deal with adding the following pairs of languages, whose names differ only by diacritical marks? aru Arua arx Aruá bfa Bari mot Barí kgm Karipúna kuq Karipuná sbe Saliba slc Sáliba wbf Wara tci Wára Are we going to include an ASCII version of every name that contains an accented letter? There are several hundred in ISO 639-3. As CE has shown above, we are already strongly considering adding duplicative Comments information to get around our own technical limitations. Will we also have to include elaborate Comments fields distinguishing the "real" Arua from the one we invented by lopping off the accent from Aruá? Section 3.1 mentions transcription of non-Latin Description fields into the Latin script. It does not talk about providing a pure-ASCII equivalent for every non-ASCII French- or Spanish-language string, and I don't believe that was the WG's intention. Transcriptions are useful when the content is in Arabic or Cyrillic or Han, to make the material available to Latin-script-only readers. Providing "transcriptions" like "4#xE8;eme (4eme)" merely announces to the world that we can't solve our own technical character-encoding problems without resorting to unwieldy kludges. We really need to take another hard, serious look at maintaining the Registry in UTF-8. The current scheme is one of the biggest sources of misunderstanding that newcomers have about the Registry, and one of the biggest bones of contention among regular list participants. We need to consider this soon, before the release of the "final" ISO 639-3 data moves RFC 4645bis onto the LTRU critical path, because the way it is decided will have huge implications for RFC 4645bis. And we need to consider it WITHOUT dragging in side discussions like XML. As far as I can tell, the objections to moving the Registry to UTF-8 are as follows: 1. UTF-8 doesn't play well with e-mail, which is invaluable for discussing changes on the ietf-languages list and sending the changes to IANA (stated by several). Clearly there are problems with the diversity of character encodings as e-mail travels from a sender's machine across the Internet and onto each recipient's client, or gets processed into Web archive pages. Even on the Unicode mailing list and mail archive pages, where you might think the problem would be solved, you can see numerous examples of this. This isn't limited to UTF-8; it is not uncommon to see Latin-1 or (especially) Windows-1252 get corrupted or displayed incorrectly. As Ira McDonald suggested, it would make sense to conduct all preliminary discussion using escape sequences or some other mechanism: "(Note: the name 'Aruá' is actually spelled 'A, r, u, a-with-acute'.)" but then send the final change to IANA in UTF-8 so they could simply drop it into the Registry with little or no editing, as they do now. We would have to figure out some way for the list to confirm that the changes seen on the list are those that are sent to IANA, with no alteration other than the recoding to UTF-8. This should not be difficult. I am willing do whatever is deemed necessary on my part to make this work. We need to figure out how to make it work, instead of using it as a reason not to adopt UTF-8. 2. Converting the Registry to UTF-8 would break existing implementations that expect hex NCRs (Addison Phillips). Addison is correct; any structural change to the Registry will break RFC 4646-conformant processors. This is true not only for UTF-8, but also for new fields such as "Macrolanguage" or "Modified." (Section 3.1 says the Type "MUST" be one of the seven currently defined values.) If there are implementations that read and interpret the Registry and will choke on non-ASCII input, whose authors are not on one of these mailing lists, then we need to get the word out that the format may change, just as we would if we decide to add new field values. Personally I doubt there are large numbers of such implementations. 3. UTF-8 can't be read on some, espcially older, computer systems (Frank Ellermann, months ago, and CE Whitehead). With the continuing adoption of Unicode by OS and software vendors, I really can't get behind this argument. It simply isn't appropriate to "dumb down" all computerized text to match the least capable systems that might be running somewhere. This is especially true considering the language names listed above. We don't restrict text to uppercase to maintain compatibility with BCDIC and Sinclair ZX81 systems. A Windows system running Internet Explorer 4.0 or above can display a local text file as UTF-8. According to Wikipedia, of the 78% of Windows machines that run IE, fewer than 1% are running a version lower than 6.0. Support for UTF-8 is probably the same, if not better, for non-Microsoft browsers; see http://www.alanwood.net/unicode/browsers.html for more information. In thinking about "display," we should step back and remember why we have a Language Subtag Registry at all. It exists to support BCP 47 language tagging by providing a complete list of all subtags that can be used to form a language tag, plus all grandfathered tags that can be used on their own. It provides some additional information, such as comments, to help tag producers and consumers make tagging decisions, but it is not intended to be a general compendium of language information, meant for casual browsing. Another possibility is to have IANA post an official version of the Registry in one encoding, such as UTF-8, and additional, unofficial versions in other encodings, such as Latin-1 or hex NCRs. This is the approach chosen by the ISO 639-3 Registration Authority. Potential problems with this approach are unintentional mismatches between the versions (I caught one of these problems for the ISO 639-3 people recently) and a perception that the "simplified" version is actually the official one. My suggestions, very simply, are: * For LTRU, to amend RFC 4646bis to change the format of the Registry to UTF-8, and to work out the details such as compatibility with existing RFC 4646 processors and avoidance of UTF-8 in e-mails. * For ietf-languages, to impose a moratorium on changes to Description and Comments fields whose only purpose is to transcribe hex NCRs to ASCII, until the matter is resolved within LTRU. -- 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 Jul 01 19:18:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I58gg-0001TP-7R; Sun, 01 Jul 2007 19:18:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I58ge-0001Je-P2 for ltru-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 19:18:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I58ge-0001JH-FQ for ltru@ietf.org; Sun, 01 Jul 2007 19:18:36 -0400 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I58gZ-0004qk-Ro for ltru@ietf.org; Sun, 01 Jul 2007 19:18:36 -0400 Received: by wa-out-1112.google.com with SMTP id k17so2369166waf for ; Sun, 01 Jul 2007 16:18:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=FgScCbJ3dJR/GkBKvoeSB/7sjavey5qb1wIESmUqSCvaTBUlWBHDFc+uazlX8mVxNadn+wDaz23xp4cXAMtP/gMEV39fw0Ue039RJ5nuuomSAh97NFgW5NNPV2aWl13eEgHre+amYhI/98rG+e+pklPmZKfe+1JJXB1vJPSQ7TA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=DrhZlcXgfFqxBJHekbhsFRk9j+Duy4JHPKcUU9eDNBIbOyLxZsLX9g7Xw+YwCWuaBTLF1xB8TkrHOS5iXXcoPGIJ6jabFOGfpXC+AedqtRRG8NbUtDd0qlNixt1xO/xb2ZzetZu3W6OcHgWfIrl9R5yHVn+9NX3f2xOoDDBFgps= Received: by 10.114.178.1 with SMTP id a1mr4541017waf.1183331910191; Sun, 01 Jul 2007 16:18:30 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Sun, 1 Jul 2007 16:18:30 -0700 (PDT) Message-ID: <30b660a20707011618m67fe32e6n73e81f8d3bddd69d@mail.gmail.com> Date: Sun, 1 Jul 2007 16:18:30 -0700 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: 672162b4f67bca1f X-Spam-Score: 0.5 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ltru] Suggested text for future compatibility of registry processors. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0768083903==" Errors-To: ltru-bounces@ietf.org --===============0768083903== Content-Type: multipart/alternative; boundary="----=_Part_117081_22776107.1183331910169" ------=_Part_117081_22776107.1183331910169 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Doug noted the following in his email on UTF-8 (on which topic I agree with him, btw). > Addison is correct; any structural change to the Registry will break RFC 4646-conformant processors. This is true not only for UTF-8, but also for new fields such as "Macrolanguage" or "Modified." (Section 3.1 says the Type "MUST" be one of the seven currently defined values.) I suggest that we add language to 4646bis noting this, with the following suggested text. Add to the end of 3.1.2. Record Definitions: Future versions of the language subtag registry may add more fields. Processors of the registry that are not intended to be updated with each successive version of BCP 47 and thus need to be compatible with future versions of the registry, SHOULD be written so as to ignore additional fields. -- Mark ------=_Part_117081_22776107.1183331910169 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Doug noted the following in his email on UTF-8 (on which topic I agree with him, btw).

> Addison is correct; any structural change to the Registry will break RFC
4646-conformant processors.  This is true not only for UTF-8, but also for
new fields such as "Macrolanguage" or "Modified."  (Section 3.1 says the
Type "MUST" be one of the seven currently defined values.)

I suggest that we add language to 4646bis noting this, with the following suggested text.

Add to the end of 3.1.2.  Record Definitions:

Future versions of the language subtag registry may add more fields. Processors of the registry that are not intended to be updated with each successive version of BCP 47 and thus need to be compatible with future versions of the registry, SHOULD be written so as to ignore additional fields.

--
Mark ------=_Part_117081_22776107.1183331910169-- --===============0768083903== 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 --===============0768083903==-- From ltru-bounces@ietf.org Sun Jul 01 19:28:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I58qD-000577-Le; Sun, 01 Jul 2007 19:28:29 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I58qC-000572-HX for ltru-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 19:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I58qC-00056t-87 for ltru@ietf.org; Sun, 01 Jul 2007 19:28:28 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I58q7-0005e1-VC for ltru@ietf.org; Sun, 01 Jul 2007 19:28:28 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I58q7-0006Nk-2V; Sun, 01 Jul 2007 19:28:23 -0400 Date: Sun, 1 Jul 2007 19:28:23 -0400 To: Doug Ewell Subject: Re: [Ltru] Solving the UTF-8 problem Message-ID: <20070701232823.GA15843@mercury.ccil.org> References: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Doug Ewell scripsit: > 1. UTF-8 doesn't play well with e-mail, which is invaluable for > discussing changes on the ietf-languages list and sending the changes to > IANA (stated by several). I note for the record that your message arrived encoded in Latin-1 but tagged "utf-8". -- We pledge allegiance to the penguin John Cowan and to the intellectual property regime cowan@ccil.org for which he stands, one world under http://www.ccil.org/~cowan Linux, with free music and open source software for all. --Julian Dibbell on Brazil, edited _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jul 01 19:38:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5906-0003jf-B6; Sun, 01 Jul 2007 19:38:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5904-0003jO-42 for ltru-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 19:38:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5903-0003jB-Qp for ltru@ietf.org; Sun, 01 Jul 2007 19:38:39 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I58zz-00075T-Fg for ltru@ietf.org; Sun, 01 Jul 2007 19:38:39 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=A9bd1oYbDa6tiOIAo2a+j4bd46yJOKf5zrQxeDjwb+xz2cfprxzkgtLpEcD/kXKt; 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 [64.105.34.104] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I58zy-0004Oq-Ql for ltru@ietf.org; Sun, 01 Jul 2007 19:38:35 -0400 Message-ID: <003f01c7bc39$08708ca0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20707011618m67fe32e6n73e81f8d3bddd69d@mail.gmail.com> Subject: Re: [Ltru] Suggested text for future compatibility of registryprocessors. Date: Sun, 1 Jul 2007 16:39:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93566b0c601d465286ba03398137085246d4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.104 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Mark Davis" > To: "LTRU Working Group" > Sent: Sunday, July 01, 2007 4:18 PM > Subject: [Ltru] Suggested text for future compatibility of registryprocessors. .... > Add to the end of 3.1.2. Record Definitions: > > Future versions of the language subtag registry may add more fields. > Processors of the registry that are not intended to be updated with each > successive version of BCP 47 and thus need to be compatible with future > versions of the registry, SHOULD be written so as to ignore additional > fields. ... I agree with the intent, but I'd like to propose a slightly different wording: Future versions of this memo MAY define additional field types for use in the language subtag registry. Consequently, software to process the content of the registry SHOULD tolerate unrecognized field types. Rationales: (1) I think this is a bit clearer and more concise (2) "tolerate" rather than "ignore" - consider the result of a typo: "Suppers-Script:" - I think one would like an implementation to be able to issue a warning, rather than simply ignoring, a field that it doesn't recognize. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jul 01 19:50:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I59BX-0000He-Un; Sun, 01 Jul 2007 19:50:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I59BW-0000FO-Nu for ltru-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 19:50:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I59BW-0000EZ-Dv for ltru@ietf.org; Sun, 01 Jul 2007 19:50:30 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I59BS-0001xu-1l for ltru@ietf.org; Sun, 01 Jul 2007 19:50:30 -0400 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 <20070701235025.JUEA26351.mta13.adelphia.net@DGBP7M81>; Sun, 1 Jul 2007 19:50:25 -0400 Message-ID: <000501c7bc3a$976f3040$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , References: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> <20070701232823.GA15843@mercury.ccil.org> Subject: Re: [Ltru] Solving the UTF-8 problem Date: Sun, 1 Jul 2007 16:50:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: >> 1. UTF-8 doesn't play well with e-mail, which is invaluable for >> discussing changes on the ietf-languages list and sending the changes to >> IANA (stated by several). > > I note for the record that your message arrived encoded in Latin-1 but > tagged "utf-8". (For reference: Microsoft Outlook Express 6.00.2900.2180.) When I saved the sent message as a text file and then opened it in a hex editor, I saw the UTF-8 sequences. So it may have been changed somewhere along the way. Maybe I should have included a non-1252 character somewhere. In any case, I don't dispute that e-mail support for UTF-8, whether in clients or gateways, is unreliable. I suggested an approach to get around that problem. -- 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 Jul 01 19:55:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I59Gd-0008PH-BF; Sun, 01 Jul 2007 19:55:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I59Gc-0008Id-49 for ltru-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 19:55:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I59Gb-0008I6-QC for ltru@ietf.org; Sun, 01 Jul 2007 19:55:45 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I59GX-00035M-13 for ltru@ietf.org; Sun, 01 Jul 2007 19:55:45 -0400 Received: by wa-out-1112.google.com with SMTP id k17so2378394waf for ; Sun, 01 Jul 2007 16:55:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=DGGesS3VZpTs/23SQArtKteoP0TdFQ93AMNQamCyBK0zIcWwbu2AZNiv0sFwrLrywoJmZ2t7+T2ihRTmJw1a/fXhxvLZBStWQlXpCS1mUlHh5IxjcCL4nodvaBfBR+hBlgNyVvQRl38QL9y63HvVxt0HuyJw35Pj5YhMZm0kDmM= 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=jCdLzlpC/bdVM8b40Hb4b95Lxav/J+LBa9Sg3Ge21sgJStTVN7ID7etys/BsqXCZY6DhZw9ymoa8Q2B5DGawIufNmcrgwrIfFPDwhkiGvTBHXQLVuGsVhmsaBmByGeoAV6r4sYFkd3QpEVD4nrLbQpDcwUqAoJmVoRx6WuVvWv0= Received: by 10.114.210.2 with SMTP id i2mr4624225wag.1183334140388; Sun, 01 Jul 2007 16:55:40 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Sun, 1 Jul 2007 16:55:40 -0700 (PDT) Message-ID: <30b660a20707011655y4c99bc31h3f1e2d63d36a91fd@mail.gmail.com> Date: Sun, 1 Jul 2007 16:55:40 -0700 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] Suggested text for future compatibility of registryprocessors. In-Reply-To: <003f01c7bc39$08708ca0$6601a8c0@oemcomputer> MIME-Version: 1.0 References: <30b660a20707011618m67fe32e6n73e81f8d3bddd69d@mail.gmail.com> <003f01c7bc39$08708ca0$6601a8c0@oemcomputer> X-Google-Sender-Auth: 912d29d1d41e4719 X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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="===============1657029124==" Errors-To: ltru-bounces@ietf.org --===============1657029124== Content-Type: multipart/alternative; boundary="----=_Part_117333_8668918.1183334140367" ------=_Part_117333_8668918.1183334140367 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Your changes sound fine by me. I do have a question. I thought MAY was only capitalized when it was in reference to conformance to this document. But in that statement it doesn't seem to apply: it doesn't appear that we in this document can make any conformance promises (positive or negative) about future versions since that is entirely in the hands of the IETF. Mark On 7/1/07, Randy Presuhn wrote: > > Hi - > > As a technical contributor... > > > From: "Mark Davis" > > To: "LTRU Working Group" > > Sent: Sunday, July 01, 2007 4:18 PM > > Subject: [Ltru] Suggested text for future compatibility of > registryprocessors. > .... > > Add to the end of 3.1.2. Record Definitions: > > > > Future versions of the language subtag registry may add more fields. > > Processors of the registry that are not intended to be updated with each > > successive version of BCP 47 and thus need to be compatible with future > > versions of the registry, SHOULD be written so as to ignore additional > > fields. > ... > > I agree with the intent, but I'd like to propose a slightly different > wording: > > Future versions of this memo MAY define additional field types for > use in the language subtag registry. Consequently, software to > process the content of the registry SHOULD tolerate unrecognized > field types. > > Rationales: > > (1) I think this is a bit clearer and more concise > (2) "tolerate" rather than "ignore" - consider the result of > a typo: "Suppers-Script:" - I think one would like an implementation > to be able to issue a warning, rather than simply ignoring, a field > that it doesn't recognize. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_117333_8668918.1183334140367 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Your changes sound fine by me. I do have a question. I thought MAY was only capitalized when it was in reference to conformance to this document. But in that statement it doesn't seem to apply: it doesn't appear that we in this document can make any conformance promises (positive or negative) about future versions since that is entirely in the hands of the IETF.

Mark

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

As a technical contributor...

> From: "Mark Davis" <mark.davis@icu-project.org>
> To: "LTRU Working Group" < ltru@ietf.org>
> Sent: Sunday, July 01, 2007 4:18 PM
> Subject: [Ltru] Suggested text for future compatibility of registryprocessors.
....
> Add to the end of 3.1.2.  Record Definitions:
>
> Future versions of the language subtag registry may add more fields.
> Processors of the registry that are not intended to be updated with each
> successive version of BCP 47 and thus need to be compatible with future
> versions of the registry, SHOULD be written so as to ignore additional
> fields.
...

I agree with the intent, but I'd like to propose a slightly different wording:

  Future versions of this memo MAY define additional field types for
  use in the language subtag registry.  Consequently, software to
  process the content of the registry SHOULD tolerate unrecognized
  field types.

Rationales:

(1) I think this is a bit clearer and more concise
(2)  "tolerate" rather than "ignore" - consider the result of
a typo: "Suppers-Script:"   - I think one would like an implementation
to be able to issue a warning, rather than simply ignoring, a field
that it doesn't recognize.

Randy



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



--
Mark ------=_Part_117333_8668918.1183334140367-- --===============1657029124== 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 --===============1657029124==-- From ltru-bounces@ietf.org Sun Jul 01 20:08:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I59Sz-0007Pd-0p; Sun, 01 Jul 2007 20:08:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I59Sy-0007KS-Gv for ltru-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 20:08:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I59Sy-0007Gz-4O for ltru@ietf.org; Sun, 01 Jul 2007 20:08:32 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I59Su-0005hx-9V for ltru@ietf.org; Sun, 01 Jul 2007 20:08:32 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l6208Q6A028390 for ; Mon, 2 Jul 2007 09:08:26 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1b89_5b21bdee_2830_11dc_8510_0014221f2a2d; Mon, 02 Jul 2007 09:08:26 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:43720) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Jul 2007 09:06:21 +0900 Message-Id: <6.0.0.20.2.20070701105325.0ac7b750@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 01 Jul 2007 11:01:32 +0900 To: "Mark Davis" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Resolving issues In-Reply-To: <30b660a20706291506jd82e202s8bbc931de10e24b3@mail.gmail.com > References: <30b660a20706291506jd82e202s8bbc931de10e24b3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 with chair hat on: At 07:06 07/06/30, Mark Davis wrote: >Addison and I have been looking over some of the remaining issues, and have worked out some suggested language to resolve some open issues. > >http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html You talk about issue*s* here, but below, I can proposed language for only one issue. Are we supposed to look at the above link for the other issues, or will language for other issues be proposed in forthcomming email, or what? Also, it would be good to give a more specific pointer, i.e. http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html#subtagreviewer >The IESG will solicit nominees for the position (initially or upon a vacancy) and seek to ascertain the candidates' qualifications. > >=> > >The IESG will solicit nominees for the position (upon adoption of this document or upon a vacancy) and then solicit feedback on the nominees' qualifications. > >Qualified candidates should be familiar with BCP 47 and its requirements; be willing to fairly, responsively, and judiciously administer the registration process; and be suitably informed about the issues of language identification so that they can draw upon and assess the claim and contributions of language experts and subtag requesters. as a technical (or, in this case, procedural) contributor: I think one big issue that isn't dealt with here is that the appointment is for an infinite term. I think it would be much better to have a limited term (e.g. two years), with a possibility for renewal. This gives a good chance for reviewing from both sides (both the reviewer as well as the IESG). 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 Jul 01 20:15:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I59Zv-0006pc-6i; Sun, 01 Jul 2007 20:15:43 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I59Zt-0006nx-Hq for ltru-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 20:15:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I59Zt-0006mN-5G for ltru@ietf.org; Sun, 01 Jul 2007 20:15:41 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I59Zp-000894-SW for ltru@ietf.org; Sun, 01 Jul 2007 20:15:41 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ST2XdryDh6eV3Y1R79HLeYh6dU1QTMseqOU7xBzUkh3sAWqU6RI2FenrkxSlHtK3; 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 [64.105.34.104] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I59Zo-0006Xl-T4 for ltru@ietf.org; Sun, 01 Jul 2007 20:15:37 -0400 Message-ID: <000701c7bc3e$3517e0a0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20707011618m67fe32e6n73e81f8d3bddd69d@mail.gmail.com> <003f01c7bc39$08708ca0$6601a8c0@oemcomputer> <30b660a20707011655y4c99bc31h3f1e2d63d36a91fd@mail.gmail.com> Subject: Re: [Ltru] Suggested text for future compatibility of registryprocessors. Date: Sun, 1 Jul 2007 17:16:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356ee67a26f632b86eed6ae115164658a53350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.104 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: "Mark Davis" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Sunday, July 01, 2007 4:55 PM > Subject: Re: [Ltru] Suggested text for future compatibility of registryprocessors. > > Your changes sound fine by me. I do have a question. I thought MAY was only > capitalized when it was in reference to conformance to this document. But in > that statement it doesn't seem to apply: it doesn't appear that we in this > document can make any conformance promises (positive or negative) about > future versions since that is entirely in the hands of the IETF. ... I was looking at it from a protocol specification perspective. When defining an extensible protocol, using SHOULD, MUST, etc. makes sense when specifying the nature of permissible extensions. If we wanted to be really pedantic, for example, we could spell out that future extensions MUST NOT violate the syntax established for "record" in the ABNF. (If we were indeed going to make a commitment to forward compatibility in the registry format. At this point, we haven't constrained ourselves in this way, and please don't read this example as an argument that we should constrain ourselves in this way. Indeed, I think we really need to discourage implementations (other than very specialized developer tools) from reading the registry itself, in much the same way as network management applications don't dynamically query the IANA enterprise number assignments.) Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jul 01 20:32:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I59qS-0007c7-Cz; Sun, 01 Jul 2007 20:32:48 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I59qR-0007c2-9z for ltru-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 20:32:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I59qR-0007bt-0Q for ltru@ietf.org; Sun, 01 Jul 2007 20:32:47 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I59qM-0003Q1-Hp for ltru@ietf.org; Sun, 01 Jul 2007 20:32:46 -0400 Received: by py-out-1112.google.com with SMTP id f31so3901947pyh for ; Sun, 01 Jul 2007 17:32:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=GKuOxQyX/GFDWyfVqMF6YWxn26IsMkyQHu3mSCUtvUdaqf8oqeGpQr6ZrxoCOz07Y3FZabAr/NutEnv3bmz1F0SQQwgJZBbJcJtuBB5jAGnHVa1G0uOvcPePL1y0bheT1FTNGoqNGX4TbL44NlFw6De4vTs7OLeTnuQd++qb2cQ= 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=NkZ0JGwCiSdSAidHjIH8H0+YwQOPPPEF9smGnx+NwG3vpcsCdpq2X4LMZd23qtSzuxZlD10RB20QxuWN8GlAPmT2k0wCmpYfYeEoCahL2Qqcy9aR5hAXyzXR0lELLKWQNvo9ynCWHRkNwPFTUOUOtW103A/zdaIBzB5PKJTIUso= Received: by 10.114.158.1 with SMTP id g1mr4629455wae.1183336360686; Sun, 01 Jul 2007 17:32:40 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Sun, 1 Jul 2007 17:32:40 -0700 (PDT) Message-ID: <30b660a20707011732n6bca450aj187400d05d3ba46c@mail.gmail.com> Date: Sun, 1 Jul 2007 17:32:40 -0700 From: "Mark Davis" To: "Martin Duerst" Subject: Re: [Ltru] Resolving issues In-Reply-To: <6.0.0.20.2.20070701105325.0ac7b750@localhost> MIME-Version: 1.0 References: <30b660a20706291506jd82e202s8bbc931de10e24b3@mail.gmail.com> <6.0.0.20.2.20070701105325.0ac7b750@localhost> X-Google-Sender-Auth: 7c0b60e3cd8d8d2b X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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="===============1766362715==" Errors-To: ltru-bounces@ietf.org --===============1766362715== Content-Type: multipart/alternative; boundary="----=_Part_117509_13498890.1183336360653" ------=_Part_117509_13498890.1183336360653 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/30/07, Martin Duerst wrote: > > with chair hat on: > > At 07:06 07/06/30, Mark Davis wrote: > >Addison and I have been looking over some of the remaining issues, and > have worked out some suggested language to resolve some open issues. > > > > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html< > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html> > > You talk about issue*s* here, but below, I can proposed language for > only one issue. Are we supposed to look at the above link for the > other issues, or will language for other issues be proposed in > forthcomming email, or what? There will be some more with separate email titles as we work through them. Also, it would be good to give a more specific pointer, i.e. > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html#subtagreviewer Good suggestion. >The IESG will solicit nominees for the position (initially or upon a > vacancy) and seek to ascertain the candidates' qualifications. > > > >=> > > > >The IESG will solicit nominees for the position (upon adoption of this > document or upon a vacancy) and then solicit feedback on the nominees' > qualifications. > > > >Qualified candidates should be familiar with BCP 47 and its requirements; > be willing to fairly, responsively, and judiciously administer the > registration process; and be suitably informed about the issues of language > identification so that they can draw upon and assess the claim and > contributions of language experts and subtag requesters. > > as a technical (or, in this case, procedural) contributor: > > I think one big issue that isn't dealt with here is that the appointment > is for an infinite term. I think it would be much better to have a > limited term (e.g. two years), with a possibility for renewal. > This gives a good chance for reviewing from both sides (both the > reviewer as well as the IESG). That sounds reasonable to me. Let's see what others think Regards, Martin. > > > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > -- Mark ------=_Part_117509_13498890.1183336360653 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/30/07, Martin Duerst <duerst@it.aoyama.ac.jp> wrote:
with chair hat on:

At 07:06 07/06/30, Mark Davis wrote:
>Addison and I have been looking over some of the remaining issues, and have worked out some suggested language to resolve some open issues.
>
><http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html> http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html<http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html>

You talk about issue*s* here, but below, I can proposed language for
only one issue. Are we supposed to look at the above link for the
other issues, or will language for other issues be proposed in
forthcomming email, or what?

There will be some more with separate email titles as we work through them.

Also, it would be good to give a more specific pointer, i.e.
http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-06.html#subtagreviewer

Good suggestion.

>The IESG will solicit nominees for the position (initially or upon a vacancy) and seek to ascertain the candidates' qualifications.
>
>=>
>
>The IESG will solicit nominees for the position (upon adoption of this document or upon a vacancy) and then solicit feedback on the nominees' qualifications.
>
>Qualified candidates should be familiar with BCP 47 and its requirements; be willing to fairly, responsively, and judiciously administer the registration process; and be suitably informed about the issues of language identification so that they can draw upon and assess the claim and contributions of language experts and subtag requesters.

as a technical (or, in this case, procedural) contributor:

I think one big issue that isn't dealt with here is that the appointment
is for an infinite term. I think it would be much better to have a
limited term (e.g. two years), with a possibility for renewal.
This gives a good chance for reviewing from both sides (both the
reviewer as well as the IESG).

That sounds reasonable to me. Let's see what others think

Regards,    Martin.





#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp




--
Mark ------=_Part_117509_13498890.1183336360653-- --===============1766362715== 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 --===============1766362715==-- From ltru-bounces@ietf.org Sun Jul 01 22:19:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5BW0-0005aQ-QC; Sun, 01 Jul 2007 22:19:48 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5BVz-0005aL-Jr for ltru-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 22:19:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5BVz-0005aD-AI for ltru@ietf.org; Sun, 01 Jul 2007 22:19:47 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5BVv-0003Tl-0O for ltru@ietf.org; Sun, 01 Jul 2007 22:19:47 -0400 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 <20070702021942.RAGS6326.mta9.adelphia.net@DGBP7M81> for ; Sun, 1 Jul 2007 22:19:42 -0400 Message-ID: <002301c7bc4f$724289b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 1 Jul 2007 19:19:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ltru] Re: Solving the UTF-8 problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 noticed that the Web-based LTRU mail archives bungled my UTF-8 mailing --which once again is an e-mail problem and not a UTF-8 problem per se -- so I'm re-posting a fragment, this time in ISO 8859-1. > What are we going to do when the ISO 639-3 code list is finalized and we > have to deal with adding the following pairs of languages, whose names > differ only by diacritical marks? > > aru Arua > arx Aruá > > bfa Bari > mot Barí > > kgm Karipúna > kuq Karipuná > > sbe Saliba > slc Sáliba > > wbf Wara > tci Wára -- 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 Jul 02 09:52:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MK9-0001tB-VW; Mon, 02 Jul 2007 09:52:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5MK8-0001sl-KM for ltru-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 09:52:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MK8-0001sd-Af for ltru@ietf.org; Mon, 02 Jul 2007 09:52:16 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5MK4-0000YG-1h for ltru@ietf.org; Mon, 02 Jul 2007 09:52:16 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id EFDDB240817; Mon, 2 Jul 2007 15:52:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 2E8D211396; Mon, 2 Jul 2007 15:47:07 +0200 (CEST) Date: Mon, 2 Jul 2007 15:47:07 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20070702134707.GB23350@sources.org> References: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group Subject: [Ltru] Re: Solving the UTF-8 problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Jul 01, 2007 at 03:58:48PM -0700, Doug Ewell wrote a message of 161 lines which said: > If there are implementations that read and interpret the Registry > and will choke on non-ASCII input, They are perfectly right: this is what RFC 4646 asks. Without this behaviour, some typos will go unnoticed. > Personally I doubt there are large numbers of such implementations. I tested my own implementation, GaBuZoMeu and I'm mortified to announce that it accepts UTF-8 without even a warning (I did not want that, I regard it as a bug). _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jul 02 09:57:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MOy-0004NM-FJ; Mon, 02 Jul 2007 09:57:16 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5MOx-0004NH-Lk for ltru-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 09:57:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MOx-0004N9-C7 for ltru@ietf.org; Mon, 02 Jul 2007 09:57:15 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5MOs-0001lM-VZ for ltru@ietf.org; Mon, 02 Jul 2007 09:57:15 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 57C6D240817; Mon, 2 Jul 2007 15:57:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 890D411649; Mon, 2 Jul 2007 15:55:33 +0200 (CEST) Date: Mon, 2 Jul 2007 15:55:33 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20070702135533.GC23350@sources.org> References: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ietf-languages@iana.org, LTRU Working Group Subject: [Ltru] Re: Solving the UTF-8 problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Jul 01, 2007 at 03:58:48PM -0700, Doug Ewell wrote a message of 161 lines which said: > Another possibility is to have IANA post an official version of the > Registry in one encoding, such as UTF-8, and additional, unofficial > versions in other encodings, such as Latin-1 or hex NCRs. Why not? Currently, we do exactly the opposite: IANA publishes the official registry in hex NCR (http://www.iana.org/assignments/language-subtag-registry) and langtag.net publishes an unofficial version in UTF-8 (http://www.langtag.net/registries/language-subtag-registry.utf8). > Potential problems with this approach are unintentional mismatches > between the versions (I caught one of these problems for the ISO > 639-3 people recently) I do not get it. If the unofficial version is produced by a program, how can a mismatch exist (unless there is a bug in the program)? And if the unofficial version is done by hand, should we tell ISO 639-3 that computers are better than people for boring and repetitive tasks? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jul 02 11:04:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5NRl-0006YU-LU; Mon, 02 Jul 2007 11:04:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5NRk-0006O4-68 for ltru-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 11:04:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5NRj-0006Mn-CZ for ltru@ietf.org; Mon, 02 Jul 2007 11:04:11 -0400 Received: from bay0-omc1-s7.bay0.hotmail.com ([65.54.246.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5NR5-0006mb-Fo for ltru@ietf.org; Mon, 02 Jul 2007 11:04:10 -0400 Received: from hotmail.com ([65.54.169.41]) by bay0-omc1-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 2 Jul 2007 08:03:30 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 Jul 2007 08:03:31 -0700 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Mon, 02 Jul 2007 15:03:27 GMT X-Originating-IP: [74.255.101.129] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com From: "CE Whitehead" To: ietf-languages@iana.org, ltru@ietf.org Bcc: Date: Mon, 02 Jul 2007 11:03:27 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 Jul 2007 15:03:31.0004 (UTC) FILETIME=[27253FC0:01C7BCBA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: dewell@roadrunner.com Subject: [Ltru] Solving the UTF-8 problem; was Language Tag Modification 1694acad; X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, I'm confused as to whether or not persons with Thai Windows only (do they exist?? I thought so) can see all Latin-1 characters properly. Also, I think adding a comment to transliterations into ascii that overlap would not be too much trouble. (But this is needed only if there are persons who have operating systems anywhere on earth who cannot see these characters). Finally, I do not think it is too much work to provide a ferw transliterations of non-ascii characters, given all the other stuff that goes into language subtag entries. And I do not mind whether it is the officialregistry in ascii and the unofficial in utf-8 or the other way around. Thanks. (I've put all this again below for people who like the context.) --C. E. Whitehead Doug Ewell dewell at roadrunner.com Mon Jul 2 00:58:48 CEST 2007 >What are we going to do when the ISO 639-3 code list is finalized and we >have to deal with adding the following pairs of languages, whose names >differ only by diacritical marks? >aru Arua >arx Aruá >bfa Bari >mot Barí >kgm Karipúna >kuq Karipuná >sbe Saliba >slc Sáliba >wbf Wara >tci Wára >Are we going to include an ASCII version of every name that contains an >accented letter? There are several hundred in ISO 639-3. I have not seen ISO 639-3; but as it so much work just to put in the comments, description, etc., that it should be trivial to add in the ascii name! As for the languages that differ only by the diacritical mark you might need a comment about this somewhere; I think it can be handled! (for non-latin charcters and for Latin if needed, eg. if there are persons in the world who cannot see these) >Section 3.1 mentions transcription of non-Latin Description fields into the >Latin script. It does not talk about providing a pure-ASCII equivalent for >every non-ASCII French- or Spanish-language string, and I don't believe >that was the WG's intention. Transcriptions are useful when the content is >in Arabic or Cyrillic or Han, to make the material available to >Latin-script-only readers. Providing "transcriptions" like "4#xE8;eme >(4eme)" merely announces to the world that we can't solve our own technical >character-encoding problems without resorting to unwieldy kludges. Are there people who only have say Thai windows, who would appreciate the transcriptions? That's what I was thinking; sorry if I'm wrong. Stephane Bortzmeyer bortzmeyer at nic.fr Mon Jul 2 15:55:33 CEST 2007 wrote: >On Sun, Jul 01, 2007 at 03:58:48PM -0700, >Doug Ewell wrote a message of 161 lines which >said: > > Another possibility is to have IANA post an official version of the > > Registry in one encoding, such as UTF-8, and additional, unofficial > > versions in other encodings, such as Latin-1 or hex NCRs. >Why not? Currently, we do exactly the opposite: IANA publishes the >official registry in hex NCR >(http://www.iana.org/assignments/language-subtag-registry) and >langtag.net publishes an unofficial version in UTF-8 >(http://www.langtag.net/registries/language-subtag-registry.utf8). Fine with me! --C. E. Whitehead cewcathar@hotmail.com _________________________________________________________________ Picture this – share your photos and you could win big! http://www.GETREALPhotoContest.com?ocid=TXT_TAGHM&loc=us _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jul 02 11:39:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Nzq-0003LA-Ci; Mon, 02 Jul 2007 11:39:26 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5Nzp-0003Kl-65 for ltru-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 11:39:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Nzo-0003Kd-Ss for ltru@ietf.org; Mon, 02 Jul 2007 11:39:24 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Nyv-0008LV-5n for ltru@ietf.org; Mon, 02 Jul 2007 11:39:24 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 882461C010A; Mon, 2 Jul 2007 17:38:28 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 837781C00F6; Mon, 2 Jul 2007 17:38:27 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 7515658EBF2; Mon, 2 Jul 2007 17:38:27 +0200 (CEST) Date: Mon, 2 Jul 2007 17:38:27 +0200 From: Stephane Bortzmeyer To: Chris Newman Message-ID: <20070702153827.GA29460@nic.fr> References: <6.0.0.20.2.20070617162143.05880c40@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20070617162143.05880c40@localhost> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-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: d17f825e43c9aed4fd65b7edddddec89 Cc: ltru@ietf.org Subject: [Ltru] Re: Adding http://www.langtag.net to LTRU WG charter page X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Jun 17, 2007 at 04:28:28PM +0900, Martin Duerst wrote a message of 23 lines which said: > There has been a proposal to add a link to http://www.langtag.net to > the LTRU WG charter page. I have asked the WG about input on this, > and have only seen positive feedback. I therefore assess that there > is WG consensus on adding a link to this page to our charter page at > http://www.ietf.org/html.charters/ltru-charter.html. Any news on that? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jul 02 15:50:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Rui-0000Zr-CM; Mon, 02 Jul 2007 15:50:24 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5Rug-0000Zl-Vv for ltru-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 15:50:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Rug-0000Zd-MU for ltru@ietf.org; Mon, 02 Jul 2007 15:50:22 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Rtk-00032o-3A for ltru@ietf.org; Mon, 02 Jul 2007 15:50:22 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=m7d/tYTjQWnWCNNl0mH+XrFuEaNkHT6TvIANLZrupfGdNmUKCFOivqcKL68D4oFV; h=Received:Message-ID:From:To: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 [66.167.206.24] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I5Rtj-0004Z3-AW for ltru@ietf.org; Mon, 02 Jul 2007 15:49:23 -0400 Message-ID: <00a701c7bce2$2ee467e0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 2 Jul 2007 12:50:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356fc2ad17f6e89bc1dccb10b60b1265ff7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.206.24 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ltru] Fw: Protocol Action: 'A MIB Textual Convention for Language Tags' to Proposed Standard X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Forwarded for your information. Randy > From: "The IESG" > To: "IETF-Announce" > Cc: "Internet Architecture Board" ; "RFC Editor" > Sent: Monday, July 02, 2007 12:37 PM > Subject: Protocol Action: 'A MIB Textual Convention for Language Tags' to Proposed Standard > > The IESG has approved the following document: > > - 'A MIB Textual Convention for Language Tags ' > as a Proposed Standard > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Dave Ward. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mcwalter-langtag-mib-03.txt > > Technical Summary > > This MIB module defines a textual convention to represent BCP 47 > (RFC4646) language tags. The intent is that this textual convention > will be imported and used in MIB modules that would otherwise define > their own representation. > > Working Group Summary > > This document was not the product of a working group. This > TC was split from the IPMCAST-MIB, which was created by the > mboned working group, as it made more sense for it to have > its own MIB module. IETF Last Call resulted in several comments, > which were addressed with a document revision. > > Protocol Quality > > Bill Fenner reviewed the document for the IESG. Juergen > Schoenwalder was the MIB Doctor. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jul 02 16:17:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5SKo-0006Ux-2j; Mon, 02 Jul 2007 16:17:22 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5SKm-0006UO-RW for ltru-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 16:17:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5SKm-0006UB-Hx for ltru@ietf.org; Mon, 02 Jul 2007 16:17:20 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5SKd-0003rY-Be for ltru@ietf.org; Mon, 02 Jul 2007 16:17:20 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 532E4240817; Mon, 2 Jul 2007 22:17:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 024CB128E0; Mon, 2 Jul 2007 22:15:55 +0200 (CEST) Date: Mon, 2 Jul 2007 22:15:55 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20070702201555.GA17967@sources.org> References: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ietf-languages@iana.org, LTRU Working Group Subject: [Ltru] Re: Solving the UTF-8 problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Jul 01, 2007 at 03:58:48PM -0700, Doug Ewell wrote a message of 161 lines which said: > 3. UTF-8 can't be read on some, espcially older, computer systems > (Frank Ellermann, months ago, and CE Whitehead). > > With the continuing adoption of Unicode by OS and software vendors, > I really can't get behind this argument. Sorry but UTF-8 adoption is far from ubiquitous. Many tools still have problems with UTF-8. I discovered today that ht://Dig, one of the two most common free search engines has no UTF-8 support at all (see http://www.htdig.org/FAQ.html#q4.27 and http://www.htdig.org/FAQ.html#q4.10) which is quite sad for a Web search engine (and, yes, the explanations they give are wrong, too). Another common example is the Postscript tool a2ps. > It simply isn't appropriate to "dumb down" all computerized text to > match the least capable systems that might be running somewhere. I understand the reasoning and, yes, switching the registry to UTF-8 might be one more signal sent to software developers, to tell them they really should upgrade but do not claim that everything is done yet. So, I basically agree that UTF-8 for the registry is better but I do not want to see bold sentences like "Anyone but Frank Ellermann can run a full UTF-8 environment by now". This is not true. > This is especially true considering the language names listed above. > We don't restrict text to uppercase to maintain compatibility with > BCDIC and Sinclair ZX81 systems. I'm not talking about dead systems but about programs which are live, used and maintained. Note from the trenches: as an implementor, I promise to follow whatever LTRU will decide and to improve my UTF-8 parsing abilities in Haskell, should we decide to use it. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jul 02 23:54:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ZT3-0007EE-LS; Mon, 02 Jul 2007 23:54:21 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5ZT2-0007Dy-8D for ltru-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 23:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ZT1-0007Dq-Uc for ltru@ietf.org; Mon, 02 Jul 2007 23:54:19 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5ZSx-0000L4-FO for ltru@ietf.org; Mon, 02 Jul 2007 23:54:19 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=G18o9SFQPHmYo8+eGNkkcZumCm2nQZ54BunIvv7k/6SqBOTIrUZebSIVoEz+CxQH; 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 [66.167.78.109] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I5ZSw-0007FO-UR for ltru@ietf.org; Mon, 02 Jul 2007 23:54:15 -0400 Message-ID: <005a01c7bd25$ebd394a0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> <20070702201555.GA17967@sources.org> Subject: Re: [Ltru] Re: Solving the UTF-8 problem Date: Mon, 2 Jul 2007 20:54:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a935606c8b0e003712adc56007253b7efc7d0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.109 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Doug Ewell" > Cc: ; "LTRU Working Group" > Sent: Monday, July 02, 2007 1:15 PM > Subject: [Ltru] Re: Solving the UTF-8 problem ... > So, I basically agree that UTF-8 for the registry is better but I do > not want to see bold sentences like "Anyone but Frank Ellermann can > run a full UTF-8 environment by now". This is not true. ... Granted, but we really need to be mindful of who the users of the registry (rather than things built using information from the registry) would be. These are the use cases that I think are important to support: 1) Developers of software packages to support localization and internationalization. It's hard to imagine them not having UTF-8 capabilities. 2) Developers of software used to identify the language(s) used in content. It's hard to imagine them not having UTF-8 capabilities. 3) Reviewers (typically linguists or technologists, I'd hope) evaluating language subtag registration requests. It's hard to imagine them not having UTF-8 capabilities, even though we've heard from two people whose circumstances prevent them from being able to use current technology. (I can't imagine continuing to work under such conditions, and don't know why they put up with it.) 4) People with a need to request a new subtag registration. If they are linguists, I'd strongly suspect that they'd have access to UTF-8 capable technology. Otherwise, I suspect they'd already be covered by (1), (2), or (3) above. Am I missing something? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 03 01:44:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5bBk-0003ee-Uo; Tue, 03 Jul 2007 01:44:36 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5bBk-0003cF-BW for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 01:44:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5bBj-0003aD-VL for ltru@ietf.org; Tue, 03 Jul 2007 01:44:35 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5bAs-0008L4-SG for ltru@ietf.org; Tue, 03 Jul 2007 01:44:35 -0400 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 <20070703054342.VAMR8388.mta11.adelphia.net@DGBP7M81>; Tue, 3 Jul 2007 01:43:42 -0400 Message-ID: <009301c7bd35$1c649a60$6401a8c0@DGBP7M81> From: "Doug Ewell" To: , "LTRU Working Group" References: Date: Mon, 2 Jul 2007 22:43:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: CE Whitehead Subject: [Ltru] Re: Solving the UTF-8 problem; was Language Tag Modification 1694acad; X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 wrote: > Hi, I'm confused as to whether or not persons with Thai Windows only (do > they exist?? I thought so) can see all Latin-1 characters properly. Not if they are unable to run either IE 4.0 or SC UniPad, either of which is supposed to work on any Windows 95 Rev B or later system. If you tell me what OS and browser you have at your disposal, I will tell you whether should be able to view http://langtag.net/registries/language-subtag-registry.utf8 correctly, either online or offline. I could also provide you with a Windows 95-compatible program that would provide a best-fit display of non-Latin-1 characters, but I suppose the library won't let you run it. Remember also that the Registry exists to provide names and descriptions that are sufficient for tag producers and consumers to make sensible tagging decisions. Does anyone disagree with that? It is not just for casual browsing. > Also, I think adding a comment to transliterations into ascii that overlap > would not be too much trouble. Nobody has ever said it would be difficult to add layers of comments. It would be troublesome, at least for me, to introduce unnecessary confusion by folding names like Arua and Aruá together and then adding comments to try to explain what we meant, instead of just spelling the names right. > (But this is needed only if there are persons who have operating systems > anywhere on earth who cannot see these characters). Anywhere on earth? This is your operational criterion, not mine. > Finally, I do not think it is too much work to provide a ferw > transliterations of non-ascii characters, given all the other stuff that > goes into language subtag entries. Nobody has ever said it would be "too much work" to add transliterations. See above. > I have not seen ISO 639-3; Then trust the examples I gave. > but as it so much work just to put in the comments, description, etc., > that it should be trivial to add in the ascii name! See above. Quick question: How many people feel my efforts on RFC 4646 have been guided by what is easiest, rather than what is right? Quoting Stephane Bortzmeyer : >> Why not? Currently, we do exactly the opposite: IANA publishes the >> official registry in hex NCR >> (http://www.iana.org/assignments/language-subtag-registry) and >> langtag.net publishes an unofficial version in UTF-8 >> (http://www.langtag.net/registries/language-subtag-registry.utf8). > > Fine with me! Can we pursue this official version/unofficial version strategy, as an alternative to loading up the Registry with excise? -- 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 Jul 03 02:00:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5bRG-0003J8-B7; Tue, 03 Jul 2007 02:00:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5bRF-0003Ir-Dp for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 02:00:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5bRF-0003Id-1y for ltru@ietf.org; Tue, 03 Jul 2007 02:00:37 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5bRE-00022j-R9 for ltru@ietf.org; Tue, 03 Jul 2007 02:00:36 -0400 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 <20070703060004.RSQW6326.mta9.adelphia.net@DGBP7M81>; Tue, 3 Jul 2007 02:00:04 -0400 Message-ID: <000701c7bd37$65947eb0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , References: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> <20070702201555.GA17967@sources.org> Date: Mon, 2 Jul 2007 23:00:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Ltru] Re: Solving the UTF-8 problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> 3. UTF-8 can't be read on some, espcially older, computer systems (Frank >> Ellermann, months ago, and CE Whitehead). > > So, I basically agree that UTF-8 for the registry is better but I do not > want to see bold sentences like "Anyone but Frank Ellermann can run a full > UTF-8 environment by now". This is not true. You're correct. I restated three objections to converting the Registry to UTF-8, and tried to show why they don't outweigh the advantages of converting. All three are, in fact, true: 1. UTF-8 doesn't play well with e-mail. 2. Converting will break processors that expect only ASCII. 3. Some computers can't display UTF-8. But we can work out the e-mail problem, and the breakage to processors is no worse than adding new fields (nor are there that many fully-conformant processors to be fixed). And the display problem is really not as much of a showstopper as it is being portrayed. People are saying that the hex escapes are a display problem too, and adding "Arua" and "Aruá (Arua)" to the Registry is going to confuse a LOT of people, no matter how many comments we add. -- 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 Jul 03 03:12:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5cZC-0001qK-Tv; Tue, 03 Jul 2007 03:12:55 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5cZC-0001mJ-0m for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 03:12:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5cZ8-0001lQ-9a for ltru@ietf.org; Tue, 03 Jul 2007 03:12:50 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5cY9-0006CL-01 for ltru@ietf.org; Tue, 03 Jul 2007 03:12:49 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 88F991C00DF; Tue, 3 Jul 2007 09:11:48 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 833861C00F6; Tue, 3 Jul 2007 09:11:46 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 7F98C58ECCA; Tue, 3 Jul 2007 09:11:46 +0200 (CEST) Date: Tue, 3 Jul 2007 09:11:46 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20070703071146.GA8412@nic.fr> References: <009301c7bd35$1c649a60$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009301c7bd35$1c649a60$6401a8c0@DGBP7M81> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.6 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ietf-languages@iana.org, LTRU Working Group Subject: [Ltru] Re: Solving the UTF-8 problem; was Language Tag Modification 1694acad; X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Jul 02, 2007 at 10:43:39PM -0700, Doug Ewell wrote a message of 74 lines which said: > Can we pursue this official version/unofficial version strategy, as > an alternative to loading up the Registry with excise? It seems a good strategy, very "better to light a candle than to complain about obscurity". I would say -1 to any decision of having *several* official versions (because it would be more work for IANA and more opportunity to have a discrepancy, something which is not serious with unofficial versions, but could be dramatic between official versions). But allow me a little troll: if we choose UTF-8, what about normalization? 1) Do not mention it (this would mean that IANA would be free to suddenly canonicalize the registry, thus making it different in a byte-to-byte comparison) 2) Mandate NFC or NFD (which means an automatic registry checker would have to check it) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 03 10:01:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5iwG-0006s2-Tj; Tue, 03 Jul 2007 10:01:08 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5iwF-0006ri-Gt for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 10:01:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5iwF-0006rY-6D for ltru@ietf.org; Tue, 03 Jul 2007 10:01:07 -0400 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5iwE-0006Jr-S0 for ltru@ietf.org; Tue, 03 Jul 2007 10:01:07 -0400 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 <20070703140018.PUGD26470.mta15.adelphia.net@DGBP7M81>; Tue, 3 Jul 2007 10:00:18 -0400 Message-ID: <001201c7bd7a$7c126ab0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: , "LTRU Working Group" References: <009301c7bd35$1c649a60$6401a8c0@DGBP7M81> <20070703071146.GA8412@nic.fr> Date: Tue, 3 Jul 2007 07:00:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] Re: Solving the UTF-8 problem; was Language Tag Modification 1694acad; X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > But allow me a little troll: if we choose UTF-8, what about > normalization? > > 1) Do not mention it (this would mean that IANA would be free to > suddenly canonicalize the registry, thus making it different in a > byte-to-byte comparison) > > 2) Mandate NFC or NFD (which means an automatic registry checker would > have to check it) There's actually nothing new here, since the Registry is already using Unicode with hex NCRs as the encoding scheme, and we would just be changing it to Unicode with UTF-8 as the encoding scheme. However, it wouldn't hurt to specify NFC somewhere in the draft. This is what we are already using and what the IETF and W3C seem to prefer. Descriptions and comments are supposed to be non-normative, so I'm not sure any user's tools would *have* to do any checking or correcting, though of course ours should. -- 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 Jul 03 11:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jzH-0003uQ-Ll; Tue, 03 Jul 2007 11:08:19 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5jzG-0003uK-7M for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 11:08:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jzF-0003uC-U8 for ltru@ietf.org; Tue, 03 Jul 2007 11:08:17 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5jyS-0007jA-97 for ltru@ietf.org; Tue, 03 Jul 2007 11:08:17 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 3 Jul 2007 08:07:28 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Tue, 3 Jul 2007 08:07:26 -0700 From: Peter Constable To: "ietf-languages@iana.org" , LTRU Working Group Date: Tue, 3 Jul 2007 08:07:18 -0700 Thread-Topic: Solving the UTF-8 problem; was Language Tag Modification 1694acad; Thread-Index: Ace9epLsgGg3D89fSReGzPIUyP5pRwACSVHA Message-ID: References: <009301c7bd35$1c649a60$6401a8c0@DGBP7M81> <20070703071146.GA8412@nic.fr> <001201c7bd7a$7c126ab0$6401a8c0@DGBP7M81> In-Reply-To: <001201c7bd7a$7c126ab0$6401a8c0@DGBP7M81> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Ltru] RE: Solving the UTF-8 problem; was Language Tag Modification 1694acad; X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 to specifying NFC (whether we use UTF-8 or NCRs). Peter -----Original Message----- From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-bounces@a= lvestrand.no] On Behalf Of Doug Ewell Sent: Tuesday, July 03, 2007 7:00 AM To: ietf-languages@iana.org; LTRU Working Group Subject: Re: Solving the UTF-8 problem; was Language Tag Modification 1694a= cad; Stephane Bortzmeyer wrote: > But allow me a little troll: if we choose UTF-8, what about > normalization? > > 1) Do not mention it (this would mean that IANA would be free to > suddenly canonicalize the registry, thus making it different in a > byte-to-byte comparison) > > 2) Mandate NFC or NFD (which means an automatic registry checker would > have to check it) There's actually nothing new here, since the Registry is already using Unicode with hex NCRs as the encoding scheme, and we would just be changing it to Unicode with UTF-8 as the encoding scheme. However, it wouldn't hurt to specify NFC somewhere in the draft. This is what we are already using and what the IETF and W3C seem to prefer. Descriptions and comments are supposed to be non-normative, so I'm not sure any user's tools would *have* to do any checking or correcting, though of course ours should. -- 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 _______________________________________________ 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 Tue Jul 03 11:14:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5k5f-0003GN-Kz; Tue, 03 Jul 2007 11:14:55 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5k5f-0003CW-16 for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 11:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5k5e-00039p-LW for ltru@ietf.org; Tue, 03 Jul 2007 11:14:54 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5k4l-0001wP-NQ for ltru@ietf.org; Tue, 03 Jul 2007 11:14:54 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 3 Jul 2007 08:13:59 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Tue, 3 Jul 2007 08:13:58 -0700 From: Peter Constable To: "ietf-languages@iana.org" , "ltru@ietf.org" Date: Tue, 3 Jul 2007 08:13:56 -0700 Thread-Topic: Solving the UTF-8 problem; was Language Tag Modification 1694acad; Thread-Index: Ace8ujsSStG5jwg8Rd2ed9wQQ+a8sQAygPRg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Ltru] RE: Solving the UTF-8 problem; was Language Tag Modification 1694acad; X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-bounces@a= lvestrand.no] On Behalf Of CE Whitehead > Hi, I'm confused as to whether or not persons with Thai Windows only (do they exist?? I thought so) can see all Latin-1 characters properly. Users of Windows 3.1 Thai would not be able to see Latin-1 characters. But = we should not be designing this registry to accommodate the limitations of = Windows 3.1, or any other obsolete software. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 03 11:25:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5kFs-0006sf-Af; Tue, 03 Jul 2007 11:25:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5kFr-0006sY-7a for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 11:25:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5kFq-0006sQ-UL for ltru@ietf.org; Tue, 03 Jul 2007 11:25:26 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5kF2-0004JU-SA for ltru@ietf.org; Tue, 03 Jul 2007 11:25:26 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 3 Jul 2007 08:24:36 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Tue, 3 Jul 2007 08:24:35 -0700 From: Peter Constable To: LTRU Working Group , "ietf-languages@iana.org" Date: Tue, 3 Jul 2007 08:24:32 -0700 Subject: RE: [Ltru] Re: Solving the UTF-8 problem Thread-Topic: [Ltru] Re: Solving the UTF-8 problem Thread-Index: Ace9N3wQ89L5lNA0Ru68eKDTbFpWkQATaZkw Message-ID: References: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> <20070702201555.GA17967@sources.org> <000701c7bd37$65947eb0$6401a8c0@DGBP7M81> In-Reply-To: <000701c7bd37$65947eb0$6401a8c0@DGBP7M81> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: Doug Ewell [mailto:dewell@roadrunner.com] > I restated three objections to converting the Registry to > UTF-8, and tried to show why they don't outweigh the > advantages of converting. All three are, in fact, true: > > 1. UTF-8 doesn't play well with e-mail. > 2. Converting will break processors that expect only ASCII. > 3. Some computers can't display UTF-8. > > But we can work out the e-mail problem +1 > And the display problem is really not as much of a > showstopper as it is being portrayed. People are saying > that the hex escapes are a display problem too... +1. I don't see the display issue as being a show-stopper at all. Anybody t= hat has a need to view this registry has access to means of viewing UTF-8. > the breakage to processors is no worse than adding new > fields (nor are there that many fully-conformant > processors to be fixed). I'm inclined to agree, but am waiting to see if anyone makes a strong count= erargument. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 03 11:29:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5kJv-00015S-I3; Tue, 03 Jul 2007 11:29:39 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5kJu-00015F-HJ for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 11:29:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5kJu-000154-76 for ltru@ietf.org; Tue, 03 Jul 2007 11:29:38 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5kJu-0008Jd-0c for ltru@ietf.org; Tue, 03 Jul 2007 11:29:38 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I5kJ7-0001bI-2a; Tue, 03 Jul 2007 11:28:49 -0400 Date: Tue, 3 Jul 2007 11:28:49 -0400 To: Peter Constable Subject: Re: [Ltru] Re: Solving the UTF-8 problem Message-ID: <20070703152848.GB27970@mercury.ccil.org> References: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> <20070702201555.GA17967@sources.org> <000701c7bd37$65947eb0$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Peter Constable scripsit: > > the breakage to processors is no worse than adding new > > fields (nor are there that many fully-conformant > > processors to be fixed). > > I'm inclined to agree, but am waiting to see if anyone makes a strong counterargument. Nobody actually knows how many fully conformant processors there are. I still think the email argument is the compelling one. We *will* have corruption no matter what. -- Income tax, if I may be pardoned for saying so, John Cowan is a tax on income. --Lord Macnaghten (1901) cowan@ccil.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 03 13:49:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5mUy-0003VZ-UN; Tue, 03 Jul 2007 13:49:12 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5mUy-0003PD-7e for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 13:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5mUx-0003IZ-N6 for ltru@ietf.org; Tue, 03 Jul 2007 13:49:11 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5mU1-0000Fp-Ic for ltru@ietf.org; Tue, 03 Jul 2007 13:49:11 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=sdmDJLY6/nLfYOXWHO/OV1MJr+BPB5/JRKu58+ydil6toeth5pEm6TKkJQXBz1QC; 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 [66.167.204.244] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I5mTw-0007n4-Rh for ltru@ietf.org; Tue, 03 Jul 2007 13:48:09 -0400 Message-ID: <004001c7bd9a$6a40e6c0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81><20070702201555.GA17967@sources.org><000701c7bd37$65947eb0$6401a8c0@DGBP7M81> <20070703152848.GB27970@mercury.ccil.org> Subject: Re: [Ltru] Re: Solving the UTF-8 problem Date: Tue, 3 Jul 2007 10:48:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a935663d9a53c65aaf2ab3644244a1925a19a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.244 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "John Cowan" > To: "Peter Constable" > Cc: ; "LTRU Working Group" > Sent: Tuesday, July 03, 2007 8:28 AM > Subject: Re: [Ltru] Re: Solving the UTF-8 problem ... > I still think the email argument is the compelling one. We *will* > have corruption no matter what. ... This argument is only meaningful for the format we use to discuss changes to the registry content. It has no bearing on the format of the registry itself. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 03 16:53:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5pNm-00014F-Rl; Tue, 03 Jul 2007 16:53:58 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5pNl-00012Q-77 for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 16:53:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5pNk-0000ze-Ko for ltru@ietf.org; Tue, 03 Jul 2007 16:53:56 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5pNg-0008DA-BS for ltru@ietf.org; Tue, 03 Jul 2007 16:53:56 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1284750nzf for ; Tue, 03 Jul 2007 13:53:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=iDmp3Shv6W2I/1ml1DNfkHCuzodafR9Br4J5+RjkXAudgJzh54DtcfW46MrZwtz+Yk2uORl6e2jEaBwBlwarMZXNyBq5Pec5Ck3QJpPcYsDDZVBAch9Tsj9qhU1cnPKUfp+ueJ0owrHvk9wtpwMoxY/GmmmBJ8yj2CxUCD0hEf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=ZP8KgP+lNKpT45pR0GKJU4OG4pBa48imuE7nnozKyA9bla6Ntxc4kyBfvvW2zdRkbwNuCipUAh3k20jhib3RxfWmW978Kw+4TxUIBxvi8IJQ4gFGsJE2DBBRyhuSDyC5SoBtHbBwDbhtOOMyuTLUfSs9NyVx8ghQxOAeu28OzLc= Received: by 10.114.123.1 with SMTP id v1mr6503926wac.1183496031666; Tue, 03 Jul 2007 13:53:51 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Tue, 3 Jul 2007 13:53:51 -0700 (PDT) Message-ID: <30b660a20707031353g6fe6496dhe1851f99678cf2c5@mail.gmail.com> Date: Tue, 3 Jul 2007 13:53:51 -0700 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: 0f0f0d49a1ec7a27 X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ltru] Announcement text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0205058036==" Errors-To: ltru-bounces@ietf.org --===============0205058036== Content-Type: multipart/alternative; boundary="----=_Part_160554_17649675.1183496031632" ------=_Part_160554_17649675.1183496031632 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Addision and I have talked this one over, and the suggestion is to add the following: In 5.1. Language Subtag Registry at the end of the paragraph starting "IANA MUST update the File-Date record...", add: Developers who are dependent upon the language subtag registry need to be informed of changes in the registry so that they can update their implementations if necessary. When any change is made to the language subtag registry, IANA MUST send an announcement message to ietf-languages-announcements@ iana.org (a self-subscribing list that only IANA can post to). -- Mark ------=_Part_160554_17649675.1183496031632 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Addision and I have talked this one over, and the suggestion is to add the following:


In 5.1. Language Subtag Registry at the end of the paragraph starting "IANA MUST update the File-Date record...", add:

Developers who are dependent upon the language subtag registry need to be informed of changes in the registry so that they can update their implementations if necessary. When any change is made to the language subtag registry, IANA MUST send an announcement message to ietf-languages-announcements@ iana.org (a self-subscribing list that only IANA can post to).

--
Mark ------=_Part_160554_17649675.1183496031632-- --===============0205058036== 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 --===============0205058036==-- From ltru-bounces@ietf.org Tue Jul 03 17:28:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5pul-0004dG-SN; Tue, 03 Jul 2007 17:28:03 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5puk-0004am-Be for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 17:28:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5puk-0004ae-27 for ltru@ietf.org; Tue, 03 Jul 2007 17:28:02 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5ptx-00075I-0c for ltru@ietf.org; Tue, 03 Jul 2007 17:28:02 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 318DA240817; Tue, 3 Jul 2007 23:27:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id C5D07111ED; Tue, 3 Jul 2007 23:23:19 +0200 (CEST) Date: Tue, 3 Jul 2007 23:23:19 +0200 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20070703212319.GA29518@sources.org> References: <30b660a20707031353g6fe6496dhe1851f99678cf2c5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20707031353g6fe6496dhe1851f99678cf2c5@mail.gmail.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: d17f825e43c9aed4fd65b7edddddec89 Cc: LTRU Working Group Subject: [Ltru] Re: Announcement text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Jul 03, 2007 at 01:53:51PM -0700, Mark Davis wrote a message of 55 lines which said: > When any change is made to the language subtag registry, IANA MUST > send an announcement message to ietf-languages-announcements@ > iana.org I am very reluctant here. Why mandating a given technique, email, while Atom might be preferred by some? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 03 17:46:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5qCS-0004YL-VB; Tue, 03 Jul 2007 17:46:20 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5qCS-0004YG-81 for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 17:46:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5qCR-0004Y7-UX for ltru@ietf.org; Tue, 03 Jul 2007 17:46:19 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5qCL-0002LE-K7 for ltru@ietf.org; Tue, 03 Jul 2007 17:46:19 -0400 Received: by wa-out-1112.google.com with SMTP id k17so3378343waf for ; Tue, 03 Jul 2007 14:46:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=saNZkUba6iUWK7oro3jIsXzC3jowcfvykAn7YkXLQy7nILluAj+ABFdeEr9zKNqm658KMS9w3ccBWjYAWnmcwfgmscXpG7HjLRzdjRJRMuk1pgz+4tMrwY3gKTPSJrUgMqgARMJI26Cc+Kx5FhCa+b2VKSAdr5YbBmNXc+FIB/E= 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=Dmo26kcvUjRug9hlQhSH1egMYGMzMe1JewLsuZYNVJQp9Z7e5AtLrnkXrdK6tE4MJLQ/qT0ce25PCMUW9otXQUh0L8XXBbKkBAZNaJfHzmEnXSTlMSStyRb635L4FlDgq70Lw5FK2M+MD00pdZ9o3lWyR2tLiiskeA+bhh5qR1s= Received: by 10.115.89.1 with SMTP id r1mr6598367wal.1183499171895; Tue, 03 Jul 2007 14:46:11 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Tue, 3 Jul 2007 14:46:11 -0700 (PDT) Message-ID: <30b660a20707031446p4a9f3b2bn6a0e8fd5fcb596c3@mail.gmail.com> Date: Tue, 3 Jul 2007 14:46:11 -0700 From: "Mark Davis" To: "Stephane Bortzmeyer" In-Reply-To: <20070703212319.GA29518@sources.org> MIME-Version: 1.0 References: <30b660a20707031353g6fe6496dhe1851f99678cf2c5@mail.gmail.com> <20070703212319.GA29518@sources.org> X-Google-Sender-Auth: 06a444e7b0efd6cb X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: LTRU Working Group Subject: [Ltru] Re: Announcement text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1385584752==" Errors-To: ltru-bounces@ietf.org --===============1385584752== Content-Type: multipart/alternative; boundary="----=_Part_161382_18129868.1183499171869" ------=_Part_161382_18129868.1183499171869 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Everybody has and can use email, so I don't think using a different mechanism that not everyone is set up to use would be the best choice. Mark On 7/3/07, Stephane Bortzmeyer wrote: > > On Tue, Jul 03, 2007 at 01:53:51PM -0700, > Mark Davis wrote > a message of 55 lines which said: > > > When any change is made to the language subtag registry, IANA MUST > > send an announcement message to ietf-languages-announcements@ > > iana.org > > I am very reluctant here. Why mandating a given technique, email, > while Atom might be preferred by some? > > -- Mark ------=_Part_161382_18129868.1183499171869 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Everybody has and can use email, so I don't think using a different mechanism that not everyone is set up to use would be the best choice.

Mark

On 7/3/07, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Jul 03, 2007 at 01:53:51PM -0700,
Mark Davis <mark.davis@icu-project.org> wrote
a message of 55 lines which said:

> When any change is made to the language subtag registry, IANA MUST
> send an announcement message to ietf-languages-announcements@
> iana.org

I am very reluctant here. Why mandating a given technique, email,
while Atom might be preferred by some?




--
Mark ------=_Part_161382_18129868.1183499171869-- --===============1385584752== 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 --===============1385584752==-- From ltru-bounces@ietf.org Tue Jul 03 21:00:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5tDq-00054f-Jm; Tue, 03 Jul 2007 20:59:58 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5tDp-00054V-6T for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 20:59:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5tDo-00054B-QZ for ltru@ietf.org; Tue, 03 Jul 2007 20:59:56 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5tDf-0002lC-CP for ltru@ietf.org; Tue, 03 Jul 2007 20:59:56 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lVcEnlX+4bk/3m4OGuvutivIHPsBlGgTNGQLQIHK4YpmjhyrsJM9k8uKEc7TFab6; 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.164.82.233] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I5tDe-0000Vb-Oe for ltru@ietf.org; Tue, 03 Jul 2007 20:59:47 -0400 Message-ID: <003401c7bdd6$b7db44c0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20707031353g6fe6496dhe1851f99678cf2c5@mail.gmail.com><20070703212319.GA29518@sources.org> <30b660a20707031446p4a9f3b2bn6a0e8fd5fcb596c3@mail.gmail.com> Subject: Re: [Ltru] Re: Announcement text Date: Tue, 3 Jul 2007 18:00:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a93567fd65adee451d8e0dd025b1855d4fa79350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.82.233 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Mark Davis" > To: "Stephane Bortzmeyer" > Cc: "LTRU Working Group" > Sent: Tuesday, July 03, 2007 2:46 PM > Subject: [Ltru] Re: Announcement text > > Everybody has and can use email, so I don't think using a different > mechanism that not everyone is set up to use would be the best choice. ... Is there *any* other IANA-maintained registry that provides such a notification service? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 03 21:14:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5tSH-0003po-5j; Tue, 03 Jul 2007 21:14:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5tSF-0003pe-A9 for ltru-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 21:14:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5tSF-0003pW-08 for ltru@ietf.org; Tue, 03 Jul 2007 21:14:51 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5tS8-00053E-Br for ltru@ietf.org; Tue, 03 Jul 2007 21:14:50 -0400 Received: from terminus.local (c-24-6-153-109.hsd1.ca.comcast.net [24.6.153.109]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id l641EgCj018213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jul 2007 18:14:43 -0700 Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 03 Jul 2007 18:14:44 -0700 X-PGP-Universal: processed; by terminus.local on Tue, 03 Jul 2007 18:14:44 -0700 In-Reply-To: <003401c7bdd6$b7db44c0$6601a8c0@oemcomputer> References: <30b660a20707031353g6fe6496dhe1851f99678cf2c5@mail.gmail.com><20070703212319.GA29518@sources.org> <30b660a20707031446p4a9f3b2bn6a0e8fd5fcb596c3@mail.gmail.com> <003401c7bdd6$b7db44c0$6601a8c0@oemcomputer> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Message-Id: From: David Conrad Subject: Re: [Ltru] Re: Announcement text Date: Tue, 3 Jul 2007 18:14:42 -0700 To: Randy Presuhn X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, Currently, when we modify the IPv4, IPv6, and ASN registries, we send out a notice to the RIRs and a few network operations mailing lists. Those are the only ones I'm aware of offhand. Rgds, -drc On Jul 3, 2007, at 6:00 PM, Randy Presuhn wrote: > Hi - > > As a technical contributor... > >> From: "Mark Davis" >> To: "Stephane Bortzmeyer" >> Cc: "LTRU Working Group" >> Sent: Tuesday, July 03, 2007 2:46 PM >> Subject: [Ltru] Re: Announcement text >> >> Everybody has and can use email, so I don't think using a different >> mechanism that not everyone is set up to use would be the best >> choice. > ... > > Is there *any* other IANA-maintained registry that provides such a > notification service? > > Randy > > > > _______________________________________________ > 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 Jul 04 01:08:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5x6M-0003b9-GA; Wed, 04 Jul 2007 01:08:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5x6L-0003aj-1l for ltru-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 01:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5x6K-0003ab-OU for ltru@ietf.org; Wed, 04 Jul 2007 01:08:28 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5x68-0002vW-El for ltru@ietf.org; Wed, 04 Jul 2007 01:08:28 -0400 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 <20070704050815.BLMO6326.mta9.adelphia.net@DGBP7M81>; Wed, 4 Jul 2007 01:08:15 -0400 Message-ID: <001901c7bdf9$53955370$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , References: Date: Tue, 3 Jul 2007 22:08:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ltru] Re: Solving the UTF-8 problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > I still think the email argument is the compelling one. We *will* > have corruption no matter what. My suggestion is that we send new and changed records to IANA in UTF-8, as file attachments, possibly zipped or gzipped or wrapped in some other sort of binary armor to help protect against damage. I'm not worried about that part; I haven't received a corrupted GIF or JPEG sent that way in 10 years. The part I'm not sure about is convincing the list that the record submitted to IANA, in this high-security way, is the exact same as the one list members have agreed upon. This is a bit touchy because of the two recent submissions whose Comments fields were altered before being sent to IANA. I'm sure we can come up with a solution that will satisfy almost everyone; I'm just not sure what that solution will be. -- 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 Jul 04 03:26:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zFp-0000Pg-FP; Wed, 04 Jul 2007 03:26:25 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5zFo-0000Pa-EY for ltru-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 03:26:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zFo-0000PS-56 for ltru@ietf.org; Wed, 04 Jul 2007 03:26:24 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5zF4-0007lv-Ma for ltru@ietf.org; Wed, 04 Jul 2007 03:26:24 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l647PbIp026223 for ; Wed, 4 Jul 2007 16:25:37 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 76e5_c2cebe1c_29ff_11dc_879f_0014221fa3c9; Wed, 04 Jul 2007 16:25:37 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36566) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 4 Jul 2007 16:23:30 +0900 Message-Id: <6.0.0.20.2.20070704153453.0c3a1050@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 04 Jul 2007 15:43:59 +0900 To: Peter Constable , LTRU Working Group , "ietf-languages@iana.org" From: Martin Duerst Subject: RE: [Ltru] Re: Solving the UTF-8 problem In-Reply-To: References: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> <20070702201555.GA17967@sources.org> <000701c7bd37$65947eb0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 00:24 07/07/04, Peter Constable wrote: >From: Doug Ewell [mailto:dewell@roadrunner.com] > >> I restated three objections to converting the Registry to >> UTF-8, and tried to show why they don't outweigh the >> advantages of converting. Dougs argument that most newcommers are confused by the numeric character references is a very strong one. >> All three are, in fact, true: >> >> 1. UTF-8 doesn't play well with e-mail. >> 2. Converting will break processors that expect only ASCII. >> 3. Some computers can't display UTF-8. >> >> But we can work out the e-mail problem > >+1 I'm confident this can be done. I'm one of the people who cannot view UTF-8 in email, but I consider that my problem, not a problem of the WG or the subtag registration mailing list. One thing we should try to get solved (if it's not already done) is to make sure that the mailing list archive serves emails with the correct charset setting. This may or may not already the case. >> And the display problem is really not as much of a >> showstopper as it is being portrayed. People are saying >> that the hex escapes are a display problem too... > >+1. I don't see the display issue as being a show-stopper at all. Anybody >that has a need to view this registry has access to means of viewing UTF-8. I strongly agree with this. >> the breakage to processors is no worse than adding new >> fields (nor are there that many fully-conformant >> processors to be fixed). > >I'm inclined to agree, but am waiting to see if anyone makes a strong >counterargument. I agree here too. There are not too many implementations that read in the registry, and of these, some are known and can be fixed, some are know to be 8-bit tolerant, and some are run only in batch mode in a central place and can be fixed when an update occurs. For the implementations where this really matters, i.e. stuff that is field-deployed with a software upgrade mechanism and polls the registry, first, such implementations should be rather rare, and second, they should have been implemented in a robust way, because with the network, there are no guarantees at all. Explained in another way, if the implementation throws up because it sees an eigth bit on a byte, and becomes completely useless (e.g. it clears its internal language information cache or just blows up), then that's a very bad implementaion. Even if we keep all our stability guarantees, there is no guarantee that the network will never turn any bits. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jul 04 03:26:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zFz-0000tb-Ny; Wed, 04 Jul 2007 03:26:35 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I5zFy-0000mZ-2b for ltru-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 03:26:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zFx-0000ZW-NS for ltru@ietf.org; Wed, 04 Jul 2007 03:26:33 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5zF2-0007lj-5T for ltru@ietf.org; Wed, 04 Jul 2007 03:26:31 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l647PWMe026198 for ; Wed, 4 Jul 2007 16:25:32 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 6b13_bfe9b90e_29ff_11dc_950c_0014221f2a2d; Wed, 04 Jul 2007 16:25:32 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36566) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 4 Jul 2007 16:23:26 +0900 Message-Id: <6.0.0.20.2.20070704125618.0b9b46d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 04 Jul 2007 15:01:59 +0900 To: David Conrad , Randy Presuhn From: Martin Duerst Subject: Re: [Ltru] Re: Announcement text In-Reply-To: References: <30b660a20707031353g6fe6496dhe1851f99678cf2c5@mail.gmail.com> <20070703212319.GA29518@sources.org> <30b660a20707031446p4a9f3b2bn6a0e8fd5fcb596c3@mail.gmail.com> <003401c7bdd6$b7db44c0$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: LTRU 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 In my (technical) opinion, I think we can do without this if we can be sure that IANA correctly handles If-Modified-Since of HTTP. Any third party can set up an email service or an Atom feed or whatever, and people who need it and trust it can subscribe to it. Regards, Martin. At 10:14 07/07/04, David Conrad wrote: >Hi, > >Currently, when we modify the IPv4, IPv6, and ASN registries, we send >out a notice to the RIRs and a few network operations mailing lists. >Those are the only ones I'm aware of offhand. > >Rgds, >-drc #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jul 04 05:23:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6157-00057k-VY; Wed, 04 Jul 2007 05:23:29 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I6156-00057f-Lk for ltru-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 05:23:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6156-00057X-C4 for ltru@ietf.org; Wed, 04 Jul 2007 05:23:28 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6152-0004rI-0g for ltru@ietf.org; Wed, 04 Jul 2007 05:23:28 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 8C70D1C00FD; Wed, 4 Jul 2007 11:23:23 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 87AFD1C009D; Wed, 4 Jul 2007 11:23:22 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 84E3358EBF1; Wed, 4 Jul 2007 11:23:22 +0200 (CEST) Date: Wed, 4 Jul 2007 11:23:22 +0200 From: Stephane Bortzmeyer To: Martin Duerst Message-ID: <20070704092322.GA9250@nic.fr> References: <30b660a20707031353g6fe6496dhe1851f99678cf2c5@mail.gmail.com> <20070703212319.GA29518@sources.org> <30b660a20707031446p4a9f3b2bn6a0e8fd5fcb596c3@mail.gmail.com> <003401c7bdd6$b7db44c0$6601a8c0@oemcomputer> <6.0.0.20.2.20070704125618.0b9b46d0@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20070704125618.0b9b46d0@localhost> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-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: 7655788c23eb79e336f5f8ba8bce7906 Cc: LTRU Working Group Subject: [Ltru] Re: Announcement text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Jul 04, 2007 at 03:01:59PM +0900, Martin Duerst wrote a message of 28 lines which said: > In my (technical) opinion, I think we can do without this if we can > be sure that IANA correctly handles If-Modified-Since of HTTP. It does. The script behind http://www.langtag.net/registries.html relies on it and it works. (The script source code, using curl, can be retrieved with Subversion at URL https://svn.langtag.net/langtag/.) > Any third party can set up an email service or an Atom feed http://www.langtag.net/registries/lsr.atom Also, if there is a syndication feed, you can have email. Several programs do so, I use rss2email (unlike what its name suggests, it works fine with Atom): http://rss2email.infogami.com/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jul 04 05:26:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I618C-0006j2-G6; Wed, 04 Jul 2007 05:26:40 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I618B-0006ix-Hm for ltru-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 05:26:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I618B-0006ip-7o for ltru@ietf.org; Wed, 04 Jul 2007 05:26:39 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6181-0005N3-Re for ltru@ietf.org; Wed, 04 Jul 2007 05:26:39 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 7F8AC1C00F7; Wed, 4 Jul 2007 11:26:29 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 79B1A1C009D; Wed, 4 Jul 2007 11:26:27 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 7690158EBF1; Wed, 4 Jul 2007 11:26:27 +0200 (CEST) Date: Wed, 4 Jul 2007 11:26:27 +0200 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20070704092627.GB9250@nic.fr> References: <30b660a20707031353g6fe6496dhe1851f99678cf2c5@mail.gmail.com> <20070703212319.GA29518@sources.org> <30b660a20707031446p4a9f3b2bn6a0e8fd5fcb596c3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20707031446p4a9f3b2bn6a0e8fd5fcb596c3@mail.gmail.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: iana@iana.org, LTRU Working Group Subject: [Ltru] Re: Announcement text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Jul 03, 2007 at 02:46:11PM -0700, Mark Davis wrote a message of 41 lines which said: > Everybody has and can use email, It was true when I started using the Internet but, today, I know some users that use RSS heavily and never email. (There is also IM, which complicates the matter. Hey, I want the IANA to set up an IRC bot which will write to #ltru!) My point is not to say that IANA must use Atom and not email, it is that no technique will suit everyone so it is probably better not to mention one in the RFC. Apart from that, as an IANA user, I would certainly *love* to have registry notifications, wether in email or in Atom, and not only for the LSR. But it is a more general IANA issue. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jul 04 10:15:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I65di-0005rT-UP; Wed, 04 Jul 2007 10:15:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I65di-0005rO-7h for ltru-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 10:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I65dh-0005rG-UX for ltru@ietf.org; Wed, 04 Jul 2007 10:15:29 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I65dH-0002HS-QQ for ltru@ietf.org; Wed, 04 Jul 2007 10:15:29 -0400 Received: from [10.72.72.144] (snvvpn1-10-72-72-c144.corp.yahoo.com [10.72.72.144]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l64EEjJJ024324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2007 07:14:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=A7O0klsGNwWD98GHRFv88tIxtaug8YOcxpX8H+xkElYIrww/V6ns11Fl17B1vk7/ Message-ID: <468BAB55.5020800@yahoo-inc.com> Date: Wed, 04 Jul 2007 07:14:45 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: Announcement text References: <30b660a20707031353g6fe6496dhe1851f99678cf2c5@mail.gmail.com> <20070703212319.GA29518@sources.org> <30b660a20707031446p4a9f3b2bn6a0e8fd5fcb596c3@mail.gmail.com> <20070704092627.GB9250@nic.fr> In-Reply-To: <20070704092627.GB9250@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I note that the IETF tends to work via email, however. There are certainly other ietf announce lists (related to the operation of the ietf) and our communication with IANA seems to be based on email. We simply making the text say that ietf-languages-announce is the minimum requirement. Certainly one could make an RSS feed for the list too. Addison Stephane Bortzmeyer wrote: > On Tue, Jul 03, 2007 at 02:46:11PM -0700, > Mark Davis wrote > a message of 41 lines which said: > >> Everybody has and can use email, > > It was true when I started using the Internet but, today, I know some > users that use RSS heavily and never email. (There is also IM, which > complicates the matter. Hey, I want the IANA to set up an IRC bot > which will write to #ltru!) > > My point is not to say that IANA must use Atom and not email, it is > that no technique will suit everyone so it is probably better not to > mention one in the RFC. > > Apart from that, as an IANA user, I would certainly *love* to have > registry notifications, wether in email or in Atom, and not only for > the LSR. But it is a more general IANA issue. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 Jul 04 13:04:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68HH-00043e-8a; Wed, 04 Jul 2007 13:04:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I68HG-00043W-HN for ltru-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 13:04:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68HG-00043O-7w for ltru@ietf.org; Wed, 04 Jul 2007 13:04:30 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I68Gz-0000SZ-5N for ltru@ietf.org; Wed, 04 Jul 2007 13:04:30 -0400 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 <20070704170412.UFTN26351.mta13.adelphia.net@DGBP7M81> for ; Wed, 4 Jul 2007 13:04:12 -0400 Message-ID: <006f01c7be5d$57c87760$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 4 Jul 2007 10:04:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ltru] Re: Announcement text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Apart from that, as an IANA user, I would certainly *love* to have > registry notifications, wether in email or in Atom, and not only for > the LSR. But it is a more general IANA issue. You could always take the easy way :-) and use a free service like WatchThatPage.com to send you an e-mail whenever the contents of http://www.iana.org/assignments/language-subtag-registry changes. -- 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 Jul 04 13:10:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68NU-0002gM-9a; Wed, 04 Jul 2007 13:10:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I68NT-0002Xu-0Q for ltru-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 13:10:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68NS-0002Vx-ML for ltru@ietf.org; Wed, 04 Jul 2007 13:10:54 -0400 Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I68NN-0002Ba-O1 for ltru@ietf.org; Wed, 04 Jul 2007 13:10:54 -0400 Received: by wa-out-1112.google.com with SMTP id k17so3796277waf for ; Wed, 04 Jul 2007 10:10:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=YzNhyAck6ul1Fsnd00NPcRAZRA+F0NxACLNKs90E2ajuwJqAVrGSvKKGjMbd/t9o2GnqcS3PtFqCwqQL+NRdzfXfYtLo5Xc36Bmr7H6tXu6O2WyRFYiCxeomkUEXcQa8uW0KMQSnY8qxeyNA45l0qSF/L/62NKq+7zHqP4/qi8s= 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=F4aWzxIpH0MPWv9V58yQ2nYSkRLivvM82dfk64jb/UCXJkFAhj98MReuRYM+jgLAfWQIHuSxkAxlXl9MS+3zaZjjcp4H7crZDFhdfM9ohnkOloOc+JNaCFpMfRPHzif1oxaNsk1sKsvF8U8IM6wfmbAmO+/oXyDSNYRmn2XLyKw= Received: by 10.114.106.1 with SMTP id e1mr7378412wac.1183569049132; Wed, 04 Jul 2007 10:10:49 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Wed, 4 Jul 2007 10:10:49 -0700 (PDT) Message-ID: <30b660a20707041010o7f2d668dr4177e9bdf326016d@mail.gmail.com> Date: Wed, 4 Jul 2007 10:10:49 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Announcement text In-Reply-To: <006f01c7be5d$57c87760$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <006f01c7be5d$57c87760$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 133f7b53b54f5390 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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="===============0057076120==" Errors-To: ltru-bounces@ietf.org --===============0057076120== Content-Type: multipart/alternative; boundary="----=_Part_13177_20120307.1183569049089" ------=_Part_13177_20120307.1183569049089 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I have not found that to be reliable. On 7/4/07, Doug Ewell wrote: > > Stephane Bortzmeyer wrote: > > > Apart from that, as an IANA user, I would certainly *love* to have > > registry notifications, wether in email or in Atom, and not only for > > the LSR. But it is a more general IANA issue. > > You could always take the easy way :-) and use a free service like > WatchThatPage.com to send you an e-mail whenever the contents of > http://www.iana.org/assignments/language-subtag-registry changes. > > -- > 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 > -- Mark ------=_Part_13177_20120307.1183569049089 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I have not found that to be reliable.

On 7/4/07, Doug Ewell <dewell@roadrunner.com> wrote:
Stephane Bortzmeyer <bortzmeyer at nic dot fr> wrote:

> Apart from that, as an IANA user, I would certainly *love* to have
> registry notifications, wether in email or in Atom, and not only for
> the LSR. But it is a more general IANA issue.

You could always take the easy way :-) and use a free service like
WatchThatPage.com to send you an e-mail whenever the contents of
http://www.iana.org/assignments/language-subtag-registry changes.

--
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



--
Mark ------=_Part_13177_20120307.1183569049089-- --===============0057076120== 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 --===============0057076120==-- From ltru-bounces@ietf.org Thu Jul 05 20:03:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6bIZ-0002r6-Gg; Thu, 05 Jul 2007 20:03:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I6bIY-0002r1-QN for ltru-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 20:03:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6bIY-0002qt-AD for ltru@ietf.org; Thu, 05 Jul 2007 20:03:46 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6bIU-0007Wf-32 for ltru@ietf.org; Thu, 05 Jul 2007 20:03:46 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I6bIT-0005XJ-7G; Thu, 05 Jul 2007 20:03:41 -0400 Date: Thu, 5 Jul 2007 20:03:41 -0400 To: Randy Presuhn Subject: Re: [Ltru] Re: Solving the UTF-8 problem Message-ID: <20070706000341.GA17436@mercury.ccil.org> References: <20070703152848.GB27970@mercury.ccil.org> <004001c7bd9a$6a40e6c0$6601a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004001c7bd9a$6a40e6c0$6601a8c0@oemcomputer> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Presuhn scripsit: > This argument is only meaningful for the format we use to discuss > changes to the registry content. It has no bearing on the format of > the registry itself. That is only so if we have some means other than email for communicating with IANA. -- 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 Thu Jul 05 22:50:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6du4-0002Yp-E9; Thu, 05 Jul 2007 22:50:40 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I6du3-0002Yk-LC for ltru-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 22:50:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6du3-0002Yc-7F for ltru@ietf.org; Thu, 05 Jul 2007 22:50:39 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6du3-0000BO-0l for ltru@ietf.org; Thu, 05 Jul 2007 22:50:39 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GnMryg1+5K8Vzl6mJY7PjbEYt4gX59nwT/+VDgK3RldfUE83cy+fIzVQpFYZF1EI; 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 [66.167.78.157] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I6dtW-0002JO-Bt for ltru@ietf.org; Thu, 05 Jul 2007 22:50:06 -0400 Message-ID: <001d01c7bf78$77fd05c0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20070703152848.GB27970@mercury.ccil.org> <004001c7bd9a$6a40e6c0$6601a8c0@oemcomputer> <20070706000341.GA17436@mercury.ccil.org> Subject: Re: [Ltru] Re: Solving the UTF-8 problem Date: Thu, 5 Jul 2007 19:50:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356e0a9ca37f0b2e2cd0eb6172c73db07e7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.157 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "John Cowan" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Thursday, July 05, 2007 5:03 PM > Subject: Re: [Ltru] Re: Solving the UTF-8 problem > > Randy Presuhn scripsit: > > > This argument is only meaningful for the format we use to discuss > > changes to the registry content. It has no bearing on the format of > > the registry itself. > > That is only so if we have some means other than email for communicating > with IANA. ... No. The format of the email discussion does not need to be the same as the format of the registry itself. That is a simplifying, but not necessary, assumption. The email discussion only needs to contain information that could be used to generate the necessary changes. Though I wouldn't want to make unnecessary work for IANA, I also think that they are quite capable of operations more sophisticated than mere cut-and-paste. The current situation is, in my opinion, a result of over-specification of the interface between the reviewer and IANA. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jul 06 04:50:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jVr-0007Aw-GD; Fri, 06 Jul 2007 04:50:03 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I6jVq-0007Aj-C2 for ltru-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 04:50:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jVq-0007Ab-2N for ltru@ietf.org; Fri, 06 Jul 2007 04:50:02 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6jVl-0001VX-7l for ltru@ietf.org; Fri, 06 Jul 2007 04:50:02 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 82D971C010F for ; Fri, 6 Jul 2007 10:49:56 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 7EFB61C0101 for ; Fri, 6 Jul 2007 10:49:56 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 72ED658EBF1 for ; Fri, 6 Jul 2007 10:49:56 +0200 (CEST) Date: Fri, 6 Jul 2007 10:49:56 +0200 From: Stephane Bortzmeyer To: LTRU Working Group Message-ID: <20070706084956.GC9579@nic.fr> References: <20070706084003.GA19701@generic-nic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070706084003.GA19701@generic-nic.net> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-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 Subject: [Ltru] Registry change of the day: prefix with more than one 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 > %% > +Type: variant > +Subtag: biske > +Description: The San Giorgio dialect of Resian > +Description: The Bila dialect of Resian > +Added: 2007-07-05 > +Prefix: sl-rozaj > +Comments: The dialect of San Giorgio/Bila is one of the four major local > + dialects of Resian > +%% First subtag(s) in the registry with a prefix which is more than one subtag. (And, yes, it triggered a bug in my programs.) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jul 06 05:00:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jg9-0004Oy-5Z; Fri, 06 Jul 2007 05:00:41 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I6jg8-0004Oo-Cs for ltru-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 05:00:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jg8-0004Ni-0j for ltru@ietf.org; Fri, 06 Jul 2007 05:00:40 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6jg7-0007BB-JO for ltru@ietf.org; Fri, 06 Jul 2007 05:00:39 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 227921C00FD; Fri, 6 Jul 2007 11:00:07 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 12B741C00F3; Fri, 6 Jul 2007 11:00:06 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 0EEC358EBE8; Fri, 6 Jul 2007 11:00:06 +0200 (CEST) Date: Fri, 6 Jul 2007 11:00:06 +0200 From: Stephane Bortzmeyer To: iana@iana.org Message-ID: <20070706090006.GD9579@nic.fr> References: <20070706084003.GA19701@generic-nic.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <20070706084003.GA19701@generic-nic.net> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-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: 7fa173a723009a6ca8ce575a65a5d813 Cc: ltru@ietf.org Subject: [Ltru] Publication of language subtag registration templates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Yesterday, several subtags were added to the Language Subtag Registry (Kore, biske, njiva, etc). The registration templates do not appear in http://www.iana.org/assignments/lang-subtags-templates/index.html Is it just a matter of time or is there, in your opinion, something wrong in the process? (I attach an email pertaining to the previous discussion about this subject.) --Kj7319i9nmIyA2yE Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from maya.nic.fr [192.134.4.160] by batilda.nic.fr with POP3 (fetchmail-6.3.6) for (single-drop); Thu, 10 May 2007 09:25:40 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id l4A7Mf5M809800 for ; Thu, 10 May 2007 09:22:41 +0200 (CEST) Received: by relay1.nic.fr (Postfix) id 0EA31A1DABC; Thu, 10 May 2007 09:22:41 +0200 (CEST) Delivered-To: bortzmeyer@nic.fr Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by relay1.nic.fr (Postfix) with ESMTP id 0A542A1D973 for ; Thu, 10 May 2007 09:22:41 +0200 (CEST) Received: from mx1.nic.fr (localhost [127.0.0.1]) by mx1.nic.fr (Postfix) with SMTP id E85BE1714040 for ; Thu, 10 May 2007 09:22:40 +0200 (CEST) Received: by mx1.nic.fr (Postfix, from userid 500) id ABDFD171408A; Thu, 10 May 2007 09:22:40 +0200 (CEST) Received: from smtp01.icann.org (smtp01.icann.org [192.0.34.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.nic.fr (Postfix) with ESMTP id 360B31714040 for ; Thu, 10 May 2007 09:22:40 +0200 (CEST) Received: from [10.0.1.5] (c-24-6-153-109.hsd1.ca.comcast.net [24.6.153.109]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id l4A7MYow018411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 May 2007 00:22:34 -0700 In-Reply-To: <20070424075553.GA31533@nic.fr> References: <002401c78635$041f5760$6401a8c0@DGBP7M81> <006901c78638$62279400$6601a8c0@oemcomputer> <20070424075553.GA31533@nic.fr> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6CCA1DB9-28DE-4C18-B60A-7BFE508E46C1@icann.org> Cc: LTRU Working Group Content-Transfer-Encoding: 7bit Old-From: David Conrad Old-Subject: Re: [Ltru] Re: Archival of registration forms Date: Thu, 10 May 2007 00:22:33 -0700 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.752.3) X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.5.10.436 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-UIDL: b4dbfbf4111a0d102c1c5eba518be86e X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.3 Old-Subject: Re: [Ltru] Re: Archival of registration forms From: David Conrad Subject: Re: Re: Archival of registration forms Received-SPF: on batilda: SPF-pass localhost is always allowed. spfquery: localhost is always allowed. Received-SPF: pass (spfquery: localhost is always allowed.) client-ip=127.0.0.1; envelope-from=; helo=mx1.nic.fr; Hi, Sorry for the slow response on this. I'll be honest and say that I'm still not entirely clear what IANA should be doing in this case, so please do not take anything I say as definitive or concrete as to how IANA will meet this community's requirements. We are definitely open to suggestions here... On Apr 24, 2007, at 12:55 AM, Stephane Bortzmeyer wrote: >> A longstanding problem which needs to be fixed. RFC 4646 section >> 3.5 requires the approved registration forms (as submitted to IANA >> by the language subtag reviewer, in my reading) to be available. > > Yes. Whatever the reason of the lack of availability (remember that > David Conrad, IANA director, wrote he is searching why) IMHO, it > should be fixed. So, we've started making the forms people submit (after approval by the IESG designated expert) available at: http://www.iana.org/assignments/lang-subtags-templates/index.html Is this what is desired? > But for LTRU, it may also be time to consider a change to make this > obligation clearer in 4646bis? Clear obligations would be deeply appreciated. >> Are the updated registration form not currently making it to IANA, > That would be strange since they receive the registration requests and > they act on it. Actually, not as I understand it. IANA only receives the approved forms sent to us by the IESG designated expert. Rgds, -drc --Kj7319i9nmIyA2yE 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 --Kj7319i9nmIyA2yE-- From ltru-bounces@ietf.org Fri Jul 06 10:38:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6oxU-0006Xh-Ep; Fri, 06 Jul 2007 10:38:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I6oxT-0006Xc-NZ for ltru-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 10:38:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6oxT-0006X5-BM for ltru@ietf.org; Fri, 06 Jul 2007 10:38:55 -0400 Received: from mta15.adelphia.net ([68.168.78.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6oxP-0004U2-MF for ltru@ietf.org; Fri, 06 Jul 2007 10:38:55 -0400 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 <20070706143851.BLX26470.mta15.adelphia.net@DGBP7M81> for ; Fri, 6 Jul 2007 10:38:51 -0400 Message-ID: <013701c7bfdb$5e927cb0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 6 Jul 2007 07:38:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Re: Publication of language subtag registration templates X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Yesterday, several subtags were added to the Language Subtag Registry > (Kore, biske, njiva, etc). > > The registration templates do not appear in > http://www.iana.org/assignments/lang-subtags-templates/index.html > > Is it just a matter of time or is there, in your opinion, something > wrong in the process? 1. I forgot and will forward these to Michael (for forwarding to IANA) within 24 hours. Note that there are no registration forms for 'Kore' and 'Zxxx' and 'mis', since these changes came as the result of changes to the core standards and not by individual request. 2. The process on this is highly unofficial. Like the one-week viewing period for final records, it is not part of RFC 4646, but the group generally agreed to it and it is included in Section 3.5 of draft-ietf-ltru-4646bis-06. Thus I will accept charges of "unofficial and proposed process" violation, but not of process violation per se. -- 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 Jul 06 12:18:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6qWA-0000Zn-CP; Fri, 06 Jul 2007 12:18:50 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I6qW9-0000Zi-53 for ltru-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 12:18:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6qW8-0000Za-RB for ltru@ietf.org; Fri, 06 Jul 2007 12:18:48 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6qW8-00019g-Hl for ltru@ietf.org; Fri, 06 Jul 2007 12:18:48 -0400 Received: from [10.72.73.9] (snvvpn1-10-72-73-c9.corp.yahoo.com [10.72.73.9]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l66GHpnW080176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 09:17:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=i0rN8put2VizKefodzwyE6am0RIGCbINfSDolPfWorluDxXPA+0Vzk3iCmFhWBF6 Message-ID: <468E6B2F.7030805@yahoo-inc.com> Date: Fri, 06 Jul 2007 09:17:51 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [Ltru] Registry change of the day: prefix with more than one subtag References: <20070706084003.GA19701@generic-nic.net> <20070706084956.GC9579@nic.fr> In-Reply-To: <20070706084956.GC9579@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Stephane Bortzmeyer wrote: > > First subtag(s) in the registry with a prefix which is more than one > subtag. (And, yes, it triggered a bug in my programs.) > > You've got to think ahead with those unit tests :-). I must admit that we've improved the text in draft-4646bis. In 4646 there is an example (and a paragraph of text) identifying this case, but it is the section on variant rather than in section 3. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 Sat Jul 07 14:27:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7F0B-0001BB-Uh; Sat, 07 Jul 2007 14:27:27 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I7F0B-00018J-Aa for ltru-confirm+ok@megatron.ietf.org; Sat, 07 Jul 2007 14:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7F0A-00016k-WC for ltru@ietf.org; Sat, 07 Jul 2007 14:27:27 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7F06-0004qe-M0 for ltru@ietf.org; Sat, 07 Jul 2007 14:27:26 -0400 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 <20070707182722.XMHF12750.mta9.adelphia.net@DGBP7M81>; Sat, 7 Jul 2007 14:27:22 -0400 Message-ID: <007401c7c0c4$74d1ad90$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 7 Jul 2007 11:27:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Ltru] Re: Solving the UTF-8 problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >>> I still think the email argument is the compelling one. We *will* >>> have corruption no matter what. >> >> This argument is only meaningful for the format we use to discuss >> changes to the registry content. It has no bearing on the format of >> the registry itself. > > That is only so if we have some means other than email for > communicating with IANA. I really think we can overcome this is we aren't limited to both (1) plain-text e-mail and (2) sending IANA something that they can paste in with no processing. I suggested sending the payload as an attachment, and Randy suggested that IANA might be able to handle some amount of post-processing. We might combine approaches: we could send hex-escaped ASCII in the body of the message *and* attach a file containing the same content in UTF-8, and leave it up to them to either post-process the hex escapes or just use the attachment. (Or we could ask them which they prefer.) Either way, there will be no shortage of eagle eyes double-checking the new Registry to make sure they did it right. -- 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 Jul 07 21:40:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7LlW-0001rG-8T; Sat, 07 Jul 2007 21:40:46 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I7LlV-0001r6-9g for ltru-confirm+ok@megatron.ietf.org; Sat, 07 Jul 2007 21:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7LlU-0001qy-Vu for ltru@ietf.org; Sat, 07 Jul 2007 21:40:44 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7LlQ-0004WH-DB for ltru@ietf.org; Sat, 07 Jul 2007 21:40:44 -0400 Received: by wa-out-1112.google.com with SMTP id k17so943185waf for ; Sat, 07 Jul 2007 18:40:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=atRbujdECmuToIoQzKOPM1NsH8z++Y5g0tHPIzctiVGpkdbSbv5QTIpRaF3iA5JjiyPEfVzwbx1jRj6BE7mdfMAmLiNV0kkwiAqRxTS3/RK5Jk1PItx9ir8yMpm2HRSJqKPBeNWp6L5JwRpQZVTWN6eJrvwRS5ZNsDPGHDpiNj0= 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=KWe15lD+M2In80UXmd7E/oprlSicqJaPmZH9MlSjpIbdSTZY40eF4YeFPCRxiD+sz/arqgiLDTieLEU7FGMSOnNTrksQwZe0pEUZ3C/ez6cs/UvW+6Gek3BJT8J/vM/dSYOA5u7i0mI6eZ2I0Qqw6O5rgYYewniPHTjDNLrhv24= Received: by 10.114.59.1 with SMTP id h1mr1930000waa.1183858839479; Sat, 07 Jul 2007 18:40:39 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Sat, 7 Jul 2007 18:40:39 -0700 (PDT) Message-ID: <30b660a20707071840q7cfeeb3boa832ad7cbc984e62@mail.gmail.com> Date: Sat, 7 Jul 2007 18:40:39 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Solving the UTF-8 problem In-Reply-To: <007401c7c0c4$74d1ad90$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <007401c7c0c4$74d1ad90$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 457dfe6882ad8a90 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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="===============0803782532==" Errors-To: ltru-bounces@ietf.org --===============0803782532== Content-Type: multipart/alternative; boundary="----=_Part_98249_1117252.1183858839437" ------=_Part_98249_1117252.1183858839437 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with that. I also think it would be a better process for IANA to incorporate the changes and post a "beta" for a quick review, only afterwards updating the official version. Without that, there is always the possibility of them posting a file, and someone using that file before the error is discovered. Witness the jv/jw goofup, where a typo became ensconced in implementations. Mark On 7/7/07, Doug Ewell wrote: > > John Cowan wrote: > > >>> I still think the email argument is the compelling one. We *will* > >>> have corruption no matter what. > >> > >> This argument is only meaningful for the format we use to discuss > >> changes to the registry content. It has no bearing on the format of > >> the registry itself. > > > > That is only so if we have some means other than email for > > communicating with IANA. > > I really think we can overcome this is we aren't limited to both (1) > plain-text e-mail and (2) sending IANA something that they can paste in > with no processing. > > I suggested sending the payload as an attachment, and Randy suggested > that IANA might be able to handle some amount of post-processing. We > might combine approaches: we could send hex-escaped ASCII in the body of > the message *and* attach a file containing the same content in UTF-8, > and leave it up to them to either post-process the hex escapes or just > use the attachment. (Or we could ask them which they prefer.) Either > way, there will be no shortage of eagle eyes double-checking the new > Registry to make sure they did it right. > > -- > 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 > -- Mark ------=_Part_98249_1117252.1183858839437 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with that. I also think it would be a better process for IANA to incorporate the changes and post a "beta" for a quick review, only afterwards updating the official version. Without that, there is always the possibility of them posting a file, and someone using that file before the error is discovered. Witness the jv/jw goofup, where a typo became ensconced in implementations.

Mark

On 7/7/07, Doug Ewell <dewell@roadrunner.com> wrote:
John Cowan <cowan at ccil dot org> wrote:

>>> I still think the email argument is the compelling one.  We *will*
>>> have corruption no matter what.
>>
>> This argument is only meaningful for the format we use to discuss
>> changes to the registry content.  It has no bearing on the format of
>> the registry itself.
>
> That is only so if we have some means other than email for
> communicating with IANA.

I really think we can overcome this is we aren't limited to both (1)
plain-text e-mail and (2) sending IANA something that they can paste in
with no processing.

I suggested sending the payload as an attachment, and Randy suggested
that IANA might be able to handle some amount of post-processing.  We
might combine approaches: we could send hex-escaped ASCII in the body of
the message *and* attach a file containing the same content in UTF-8,
and leave it up to them to either post-process the hex escapes or just
use the attachment.  (Or we could ask them which they prefer.)  Either
way, there will be no shortage of eagle eyes double-checking the new
Registry to make sure they did it right.

--
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



--
Mark ------=_Part_98249_1117252.1183858839437-- --===============0803782532== 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 --===============0803782532==-- From ltru-bounces@ietf.org Sat Jul 07 22:18:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7MM3-0004Z2-C5; Sat, 07 Jul 2007 22:18:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I7MM2-0004V8-R4 for ltru-confirm+ok@megatron.ietf.org; Sat, 07 Jul 2007 22:18:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7MM2-0004Sb-Fw for ltru@ietf.org; Sat, 07 Jul 2007 22:18:30 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7MM2-0001xx-8q for ltru@ietf.org; Sat, 07 Jul 2007 22:18:30 -0400 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 <20070708021756.WZXF8388.mta11.adelphia.net@DGBP7M81>; Sat, 7 Jul 2007 22:17:56 -0400 Message-ID: <008701c7c106$31f2d1b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <007401c7c0c4$74d1ad90$6401a8c0@DGBP7M81> <30b660a20707071840q7cfeeb3boa832ad7cbc984e62@mail.gmail.com> Subject: Re: [Ltru] Re: Solving the UTF-8 problem Date: Sat, 7 Jul 2007 19:17:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > I also think it would be a better process for IANA to incorporate the > changes and post a "beta" for a quick review, only afterwards updating > the official version. Without that, there is always the possibility of > them posting a file, and someone using that file before the error is > discovered. Witness the jv/jw goofup, where a typo became ensconced in > implementations. Will people have the patience to wait a few days before going ahead and using the beta as if it were official? If they don't, that eliminates the whole benefit of having a beta. -- 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 Jul 08 11:04:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7YIu-0001RT-Hc; Sun, 08 Jul 2007 11:04:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I7YIs-0001RI-On for ltru-confirm+ok@megatron.ietf.org; Sun, 08 Jul 2007 11:04:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7YIs-0001R0-EM for ltru@ietf.org; Sun, 08 Jul 2007 11:04:02 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7YIo-0006N1-3I for ltru@ietf.org; Sun, 08 Jul 2007 11:04:02 -0400 Received: from [10.72.76.143] (snvvpn2-10-72-76-c143.corp.yahoo.com [10.72.76.143]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l68F3Vxd024906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2007 08:03:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=yMEoc2I3pHoL45vSVBg4gYDqOIIOpBKscLZi17sD0iB8yu27Ay2k1cVAMxtwCAp7 Message-ID: <4690FCC1.9070607@yahoo-inc.com> Date: Sun, 08 Jul 2007 08:03:29 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Solving the UTF-8 problem References: <007401c7c0c4$74d1ad90$6401a8c0@DGBP7M81> <30b660a20707071840q7cfeeb3boa832ad7cbc984e62@mail.gmail.com> <008701c7c106$31f2d1b0$6401a8c0@DGBP7M81> In-Reply-To: <008701c7c106$31f2d1b0$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 > Will people have the patience to wait a few days before going ahead and > using the beta as if it were official? If they don't, that eliminates > the whole benefit of having a beta. The only fields that can contain non-ASCII characters are Description and Comment fields. Neither has a stability guarantee and neither is normative. A data encoding error, furthermore, would probably cause implementation failures rather than lead to enshrinement of mojibake. A beta period for the registry is critical for stabilized fields. However, I note that IANA wouldn't ever change a record sent by the LSR (we require whole records to be sent) and we introduced a "beta-period" for the final record in 4646bis. An additional beta for the registry seems like gilding the lily. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 Jul 08 20:13:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7gsV-000063-FS; Sun, 08 Jul 2007 20:13:23 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I7gsB-0008Pd-Jx for ltru-confirm+ok@megatron.ietf.org; Sun, 08 Jul 2007 20:13:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7gsB-0008PU-38 for ltru@ietf.org; Sun, 08 Jul 2007 20:13:03 -0400 Received: from ms-smtp-01.rdc-kc.rr.com ([24.94.166.115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7gs6-0005TR-Bj for ltru@ietf.org; Sun, 08 Jul 2007 20:13:02 -0400 Received: from [192.168.2.2] (CPE-65-30-31-71.kc.res.rr.com [65.30.31.71]) by ms-smtp-01.rdc-kc.rr.com (8.13.6/8.13.6) with ESMTP id l690BGoY013422; Sun, 8 Jul 2007 19:11:21 -0500 (CDT) Message-ID: <46917D05.8020602@gmail.com> Date: Sun, 08 Jul 2007 19:10:45 -0500 From: =?UTF-8?B?IlJlc2hhdCBTYWJpcSAoUmXFn2F0KSI=?= User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] UTF-8 References: <467ABA07.5010306@gmail.com> <20070621180158.GC9078@mercury.ccil.org> <41a006820706211153r45ef3094p169901d87cb910d4@mail.gmail.com> <20070621185738.GE9078@mercury.ccil.org> <467C031F.4070509@gmail.com> <467C0864.9070100@gmail.com> In-Reply-To: <467C0864.9070100@gmail.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=262839AF; url=http://keyserver.veridis.com:11371 Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-01.rdc-kc.rr.com id l690BGoY013422 X-Spam-Score: 0.5 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ltru@ietf.org, GerardM X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reshat Sabiq (Re=C5=9Fat) yazm=C4=B1=C5=9F: > As far as passivity, if this takes effect w/ the next release of the > registry spec, and people know about it in advance, then it's natural > for it to not be passive. For temporary passivity, the old registry > could continue to exist w/o updates at the existing URL, and the new > registry to be updated could be exposed thru a new URL. > That happened in java betweem 1.3 and 1.4, and 1.4 and 5: it's > inevitable at early stages, and maybe even beyond. Deep down, do we not > all know that it will be UTF-8 and XML at some point? I think we do, so > passivity question will come up anyway, it's just a matter of managing > it well. I can't afford to stay abreast of the discussion, but i'd like to elaborate on my idea for passivity, w/ a SOAP standards example: The namespaces for the SOAP schemas change from version to version. For instance: 1.2: http://www.w3.org/2003/05/soap-envelope 1.1: http://schemas.xmlsoap.org/soap/envelope/ If you wanted to have http://www.iana.org/assignments/language-subtag-registry passive, then UTF-based registry would just need to use a different namespace (when using XML), and/or URL, such as: http://www.iana.org/assignments/4646bis/language-subtag-registry If you want to give people 3 years to get ready for it, then this could be planned as such for year 2010, and then it'd be some xxxx standard above instead of 4646bis. Or if, you'd like to have only 1 namespace for UTF-8-based registry, then it could be something like (and then it wouldn't change from 4646bis to xxxx to yyyy, etc.): http://www.iana.org/assignments/utf-8/language-subtag-registry My 2 cents, Re=C5=9Fat. P.S. Let's also schedule (log a bug, if possible) http://www1.ietf.org/mail-archive/web/ltru/current/ app to handle UTF-8. ;) - -- My public GPG key (ID 0x262839AF) is at: http://keyserver.veridis.com:113= 71 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFGkX0FO75ytyYoOa8RAp52AJ4hV9jle1x0ug33zZw7zHP5f5wluACdEpRl NQZV7tKIhlP3Bt75u0n7CEw=3D =3DXKwp -----END PGP SIGNATURE----- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jul 08 22:31:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7j2H-00089u-62; Sun, 08 Jul 2007 22:31:37 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I7j2F-00089m-QN for ltru-confirm+ok@megatron.ietf.org; Sun, 08 Jul 2007 22:31:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7j2F-00089d-F7 for ltru@ietf.org; Sun, 08 Jul 2007 22:31:35 -0400 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7j2F-0001PL-3n for ltru@ietf.org; Sun, 08 Jul 2007 22:31:35 -0400 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 <20070709023045.RCLK16178.mta15.adelphia.net@DGBP7M81>; Sun, 8 Jul 2007 22:30:45 -0400 Message-ID: <000901c7c1d1$27180640$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <007401c7c0c4$74d1ad90$6401a8c0@DGBP7M81> <30b660a20707071840q7cfeeb3boa832ad7cbc984e62@mail.gmail.com> <008701c7c106$31f2d1b0$6401a8c0@DGBP7M81> <4690FCC1.9070607@yahoo-inc.com> Subject: Re: [Ltru] Re: Solving the UTF-8 problem Date: Sun, 8 Jul 2007 19:30:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 beta period for the registry is critical for stabilized fields. > However, I note that IANA wouldn't ever change a record sent by the > LSR (we require whole records to be sent) and we introduced a > "beta-period" for the final record in 4646bis. An additional beta for > the registry seems like gilding the lily. I agree that we want to avoid adding excessive process to our interface with IANA. Some other RFCs that specify IANA registries spend much less time describing the exact steps than we do. To play devil's advocate, however, there were four IANA-originated errors in the LSR during 2006, and I'm sure the rest of us agree with Mark that we want to avoid this. It might be noted that the jv/jw problem in ISO 639 went unnoticed for several years, greatly increasing the likelihood that implementers would use the wrong code element. Right now there are quite a few people watching the updates to the LSR, which should prevent any errors from lingering for long. But there's no way to guarantee that this situation will continue. -- 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 Jul 08 22:44:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7jEw-0006RH-Tt; Sun, 08 Jul 2007 22:44:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I7jEv-0006Qy-Bx for ltru-confirm+ok@megatron.ietf.org; Sun, 08 Jul 2007 22:44:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7jEv-0006Qq-1l for ltru@ietf.org; Sun, 08 Jul 2007 22:44:41 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7jEr-0000BQ-Qb for ltru@ietf.org; Sun, 08 Jul 2007 22:44:41 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I7jEr-0002GZ-Hk; Sun, 08 Jul 2007 22:44:37 -0400 Date: Sun, 8 Jul 2007 22:44:37 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Solving the UTF-8 problem Message-ID: <20070709024437.GH10692@mercury.ccil.org> References: <007401c7c0c4$74d1ad90$6401a8c0@DGBP7M81> <30b660a20707071840q7cfeeb3boa832ad7cbc984e62@mail.gmail.com> <008701c7c106$31f2d1b0$6401a8c0@DGBP7M81> <4690FCC1.9070607@yahoo-inc.com> <000901c7c1d1$27180640$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000901c7c1d1$27180640$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 agree that we want to avoid adding excessive process to our interface > with IANA. Some other RFCs that specify IANA registries spend much less > time describing the exact steps than we do. AFAIK none of those registries are machine-processable, however; they are meant to be read by human implementers. -- John Cowan http://ccil.org/~cowan Micropayment advocates mistakenly believe that efficient allocation of resources is the purpose of markets. Efficiency is a byproduct of market systems, not their goal. The reasons markets work are not because users have embraced efficiency but because markets are the best place to allow users to maximize their preferences, and very often their preferences are not for conservation of cheap resources. --Clay Shirkey _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jul 09 00:39:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7l1f-0005cP-Nm; Mon, 09 Jul 2007 00:39:09 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I7l1e-0005cE-F9 for ltru-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 00:39:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7l1e-0005c5-4Y for ltru@ietf.org; Mon, 09 Jul 2007 00:39:06 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7l1d-000403-Tg for ltru@ietf.org; Mon, 09 Jul 2007 00:39:06 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=K7lUgJTzSIwHxtSqbEGKabzdHrCknVDJ2ui61yuiPwFabgCIEPGzY1YP6CWpwbzz; 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 [64.105.137.212] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I7l17-00016y-5g for ltru@ietf.org; Mon, 09 Jul 2007 00:38:33 -0400 Message-ID: <000601c7c1e3$1bb78f20$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <007401c7c0c4$74d1ad90$6401a8c0@DGBP7M81><30b660a20707071840q7cfeeb3boa832ad7cbc984e62@mail.gmail.com><008701c7c106$31f2d1b0$6401a8c0@DGBP7M81><4690FCC1.9070607@yahoo-inc.com><000901c7c1d1$27180640$6401a8c0@DGBP7M81> <20070709024437.GH10692@mercury.ccil.org> Subject: Re: [Ltru] Re: Solving the UTF-8 problem Date: Sun, 8 Jul 2007 21:39:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a935610ed9881a2fc94f7a0d5d3428f274430350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.137.212 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "John Cowan" > To: "Doug Ewell" > Cc: "LTRU Working Group" > Sent: Sunday, July 08, 2007 7:44 PM > Subject: Re: [Ltru] Re: Solving the UTF-8 problem ... > AFAIK none of those registries are machine-processable, however; > they are meant to be read by human implementers. ... Though not necessarily specified as machine-processable, some have long been used by some development tools as though they were. For example, http://www.iana.org/assignments/enterprise-numbers, simply due to the infeasibility of processing its content by hand, has been treated as machine readable, even though the documentation of the format (which has evolved over the years) is just some comments in the file itself. Ltru has gone to unusual lengths to formalize both processes and formats. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 10 01:57:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I88ik-0000fV-Ie; Tue, 10 Jul 2007 01:57:10 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I88ij-0000fQ-EJ for ltru-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 01:57:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I88ii-0000fG-T9 for ltru@ietf.org; Tue, 10 Jul 2007 01:57:09 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I88ii-00030Q-Jb for ltru@ietf.org; Tue, 10 Jul 2007 01:57:08 -0400 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 <20070710055635.TUNW19079.mta11.adelphia.net@DGBP7M81> for ; Tue, 10 Jul 2007 01:56:35 -0400 Message-ID: <006501c7c2b7$126dd4e0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 9 Jul 2007 22:56:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Ltru] Re: Registry change of the day: prefix with more than one 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 Addison Phillips replied to Stéphane Bortzmeyer: >> First subtag(s) in the registry with a prefix which is more than one >> subtag. (And, yes, it triggered a bug in my programs.) > > You've got to think ahead with those unit tests :-). I must admit that > we've improved the text in draft-4646bis. In 4646 there is an example > (and a paragraph of text) identifying this case, but it is the section > on variant rather than in section 3. Now It Can Be Told: Stéphane's bug finally motivated me to, um, add complex-prefix support to my own tag-generating and -analyzing program, which I'd talked about quite a bit but had never released, due to (a) lack of said support and (b) lack of an installer package (which may be solved shortly). While adding support for complex prefixes, I noticed that there is still some wiggle room in the rules about which variants should and should not be used with which prefixes. Here is the relevant passage from draft-ietf-ltru-4646bis-06, Section 2.2.5, which is unchanged from RFC 4646: << Most variants that share a prefix are mutually exclusive. For example, the German orthographic variations '1996' and '1901' SHOULD NOT be used in the same tag, as they represent the dates of different spelling reforms. A variant that can meaningfully be used in combination with another variant SHOULD include a 'Prefix' field in its registry record that lists that other variant. For example, if another German variant 'example' were created that made sense to use with '1996', then 'example' should include two Prefix fields: "de" and "de-1996". >> A human can easily see that "de-1901-1996" and "sl-rozaj-njiva" are meaningless, because the variants are clearly contradictory. But a few variants with the same prefix can in fact be used together, such as "en-scouse-fonipa" or "en-boont-fonipa". In fact, 'fonipa' and 'fonupa' have no prefix and can thus theoretically be used with any tag, but some combinations like "el-monoton-fonipa" are inappropriate nonetheless. I can't think of a clean way to tell software which variants can be used together and which cannot, beyond the clear rule that all subtags in the prefix must be present -- for example, you can't use 'njiva' unless both 'sl' and 'rozaj' are both present. At http://users.adelphia.net/~dewell/prefix-anomaly.html you can find an illustration of this situation. The drop-down list of variant subtags for "sl-rozaj" shows not only the reasonable choices, like 'fonipa' (no prefix) and 'njiva' (prefix = "sl-rozaj"), but also the inappropriate 'nedis' (prefix = "sl"). What information is available in either RFC 4646(bis) or in the Registry that would help software to make this decision? Does a prefix of "language with no variant" mean that the variant should not be used in the presence of any other variant? How does one determine that "en-scouse-fonipa" is OK while "el-monoton-fonipa" is not? -- 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 Jul 10 02:02:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I88nh-0004oY-UI; Tue, 10 Jul 2007 02:02:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I88ng-0004oS-8i for ltru-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 02:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I88nf-0004oK-Uo for ltru@ietf.org; Tue, 10 Jul 2007 02:02:15 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I88nX-0000Zf-Pg for ltru@ietf.org; Tue, 10 Jul 2007 02:02:15 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6A627p7021388 for ; Tue, 10 Jul 2007 06:02:07 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKY00A018HPFP00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ltru@ietf.org; Tue, 10 Jul 2007 00:02:07 -0600 (MDT) Received: from [10.0.1.21] (216-165-236-126.championbroadband.com [216.165.236.126]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKY00DT88RFKZ10@mail-amer.sun.com>; Tue, 10 Jul 2007 00:02:06 -0600 (MDT) Date: Mon, 09 Jul 2007 23:02:23 -0700 From: Chris Newman Subject: Re: [Ltru] Resolving issues In-reply-to: <30b660a20707011732n6bca450aj187400d05d3ba46c@mail.gmail.com> To: Mark Davis , Martin Duerst Message-id: <3A5A0E7C33578AA7170CB186@[10.0.1.21]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <30b660a20706291506jd82e202s8bbc931de10e24b3@mail.gmail.com> <6.0.0.20.2.20070701105325.0ac7b750@localhost> <30b660a20707011732n6bca450aj187400d05d3ba46c@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Mark Davis wrote on 7/1/07 17:32 -0700: > I think one big issue that isn't dealt with here is that the appointment > is for an infinite term. I think it would be much better to have a > limited term (e.g. two years), with a possibility for renewal. > This gives a good chance for reviewing from both sides (both the > reviewer as well as the IESG). Having to review _every_ expert reviewer every two years would be a significant time commitment for the IESG (there are a _lot_ of expert reviewers -- 100+). I'd rather apply the "if it's not broken, don't fix it" principle to expert reviewers as that's more scalable. If the community has problems with an expert reviewer, please express those concerns directly to the expert reviewer and if that doesn't satisfy, contact an appropriate area director or the IESG. - Chris _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 10 02:09:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I88uF-0002GL-BG; Tue, 10 Jul 2007 02:09:03 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I88uE-0002GG-SR for ltru-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 02:09:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I88uD-0002G7-VQ for ltru@ietf.org; Tue, 10 Jul 2007 02:09:01 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I88uD-0003Gi-Cz for ltru@ietf.org; Tue, 10 Jul 2007 02:09:01 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6A67W5L016038 for ; Tue, 10 Jul 2007 06:07:32 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKY00A018HPFP00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ltru@ietf.org; Tue, 10 Jul 2007 00:07:32 -0600 (MDT) Received: from [10.0.1.21] (216-165-236-126.championbroadband.com [216.165.236.126]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKY00DUC90IKZ10@mail-amer.sun.com>; Tue, 10 Jul 2007 00:07:32 -0600 (MDT) Date: Mon, 09 Jul 2007 23:07:49 -0700 From: Chris Newman In-reply-to: <20070702153827.GA29460@nic.fr> To: Stephane Bortzmeyer Message-id: <07A1080A17F3D712DC0FDB0A@[10.0.1.21]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <6.0.0.20.2.20070617162143.05880c40@localhost> <20070702153827.GA29460@nic.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org Subject: [Ltru] Re: Adding http://www.langtag.net to LTRU WG charter page X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Looks like the charter page has the link now. - Chris Stephane Bortzmeyer wrote on 7/2/07 17:38 +0200: > On Sun, Jun 17, 2007 at 04:28:28PM +0900, > Martin Duerst wrote > a message of 23 lines which said: > >> There has been a proposal to add a link to http://www.langtag.net to >> the LTRU WG charter page. I have asked the WG about input on this, >> and have only seen positive feedback. I therefore assess that there >> is WG consensus on adding a link to this page to our charter page at >> http://www.ietf.org/html.charters/ltru-charter.html. > > Any news on that? > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 10 02:26:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I89BV-0007ym-1O; Tue, 10 Jul 2007 02:26:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I89BT-0007yg-Ju for ltru-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 02:26:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I89BT-0007yY-8L for ltru@ietf.org; Tue, 10 Jul 2007 02:26:51 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I89BP-00015N-0S for ltru@ietf.org; Tue, 10 Jul 2007 02:26:51 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I89BO-0007oy-PK; Tue, 10 Jul 2007 02:26:46 -0400 Date: Tue, 10 Jul 2007 02:26:46 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Registry change of the day: prefix with more than one subtag Message-ID: <20070710062646.GD4426@mercury.ccil.org> References: <006501c7c2b7$126dd4e0$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006501c7c2b7$126dd4e0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: > What information is available in either RFC 4646(bis) or in the Registry > that would help software to make this decision? Does a prefix of > "language with no variant" mean that the variant should not be used in > the presence of any other variant? How does one determine that > "en-scouse-fonipa" is OK while "el-monoton-fonipa" is not? I think there is no hope of getting this right automatically. The Prefix: field gives some guidance, but even it is only a SHOULD. That said, people who use multiple prefixes probably wouldn't bother unless they know what they are doing. Indeed, the same can be said of most kinds of generativity. -- John Cowan cowan@ccil.org http://ccil.org/~cowan There was an old man Said with a laugh, "I From Peru, whose lim'ricks all Cut them in half, the pay is Look'd like haiku. He Much better for two." --Emmet O'Brien _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 10 02:39:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I89NV-00080H-6u; Tue, 10 Jul 2007 02:39:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I89NU-00080C-AV for ltru-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 02:39:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I89NT-000803-J1 for ltru@ietf.org; Tue, 10 Jul 2007 02:39:15 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I89NT-0003oi-48 for ltru@ietf.org; Tue, 10 Jul 2007 02:39:15 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6A6bsET021827 for ; Tue, 10 Jul 2007 06:37:54 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKY00C019IIME00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ltru@ietf.org; Tue, 10 Jul 2007 00:37:54 -0600 (MDT) Received: from [10.0.1.21] (216-165-236-126.championbroadband.com [216.165.236.126]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKY00DYZAF2KZ10@mail-amer.sun.com>; Tue, 10 Jul 2007 00:37:53 -0600 (MDT) Date: Mon, 09 Jul 2007 23:38:10 -0700 From: Chris Newman Subject: Re: [Ltru] Re: Solving the UTF-8 problem In-reply-to: <000701c7bd37$65947eb0$6401a8c0@DGBP7M81> To: Doug Ewell , LTRU Working Group , ietf-languages@iana.org Message-id: <490E048F8E5A21C40359DB47@[10.0.1.21]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> <20070702201555.GA17967@sources.org> <000701c7bd37$65947eb0$6401a8c0@DGBP7M81> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 on 7/2/07 23:00 -0700: > Stephane Bortzmeyer wrote: > >>> 3. UTF-8 can't be read on some, espcially older, computer systems (Frank >>> Ellermann, months ago, and CE Whitehead). >> >> So, I basically agree that UTF-8 for the registry is better but I do not >> want to see bold sentences like "Anyone but Frank Ellermann can run a full >> UTF-8 environment by now". This is not true. > > You're correct. I restated three objections to converting the Registry to > UTF-8, and tried to show why they don't outweigh the advantages of > converting. All three are, in fact, true: > > 1. UTF-8 doesn't play well with e-mail. > 2. Converting will break processors that expect only ASCII. > 3. Some computers can't display UTF-8. > > But we can work out the e-mail problem, and the breakage to processors is no > worse than adding new fields (nor are there that many fully-conformant > processors to be fixed). And the display problem is really not as much of a > showstopper as it is being portrayed. People are saying that the hex escapes > are a display problem too, and adding "Arua" and "Aruá (Arua)" to the > Registry is going to confuse a LOT of people, no matter how many comments we > add. UTF-8 has been the recommend charset for Internet interchange since RFC 2277. Our past experience with ASCII encodings of non-ASCII text in the IETF has been questionable. RFC 2047, 2231, IMAP modified-UTF-7, and quoted-printable have all had mixed results. Meanwhile, UTF-8 based IETF protocols have been less problematic from an interoperability viewpoint. The EAI WG is putting together an experiment to try UTF-8 in email headers and addresses and that will increase the pressure to update email infrastructure. Rough edges are inevitable during the adoption of new technology, but where do we want to be 5-10 years from now? What's the least painful path to get there? - Chris _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 10 03:06:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I89nj-0003AR-UI; Tue, 10 Jul 2007 03:06:23 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I89nj-0003AM-6P for ltru-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 03:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I89nf-00039z-4A for ltru@ietf.org; Tue, 10 Jul 2007 03:06:19 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I89nb-0001u0-Pu for ltru@ietf.org; Tue, 10 Jul 2007 03:06:19 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 5592E1C00E3; Tue, 10 Jul 2007 09:06:15 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 512971C0090; Tue, 10 Jul 2007 09:06:15 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 4505D58EBE8; Tue, 10 Jul 2007 09:06:15 +0200 (CEST) Date: Tue, 10 Jul 2007 09:06:15 +0200 From: Stephane Bortzmeyer To: Chris Newman Message-ID: <20070710070615.GA23563@nic.fr> References: <6.0.0.20.2.20070617162143.05880c40@localhost> <20070702153827.GA29460@nic.fr> <07A1080A17F3D712DC0FDB0A@[10.0.1.21]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07A1080A17F3D712DC0FDB0A@[10.0.1.21]> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-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: 7aefe408d50e9c7c47615841cb314bed Cc: ltru@ietf.org Subject: [Ltru] Re: Adding http://www.langtag.net to LTRU WG charter page X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Jul 09, 2007 at 11:07:49PM -0700, Chris Newman wrote a message of 21 lines which said: > Looks like the charter page has the link now. Great, thanks. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 10 09:12:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8FVa-0007Av-Q2; Tue, 10 Jul 2007 09:12:02 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8FVZ-0007Ad-Op for ltru-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 09:12:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8FVZ-0007AV-DI for ltru@ietf.org; Tue, 10 Jul 2007 09:12:01 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8FVK-0004uU-VC for ltru@ietf.org; Tue, 10 Jul 2007 09:12:01 -0400 Received: from [10.72.72.90] (snvvpn1-10-72-72-c90.corp.yahoo.com [10.72.72.90]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l6AD9axq098978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2007 06:09:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=spG96KHIj1bEL4hQGFYBMX9OX2+H1zOeWSUYyeZcemItZ3PRhkAaeZ54a1U/1ZTF Message-ID: <4693850D.3090708@yahoo-inc.com> Date: Tue, 10 Jul 2007 06:09:33 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Registry change of the day: prefix with more than one subtag References: <006501c7c2b7$126dd4e0$6401a8c0@DGBP7M81> In-Reply-To: <006501c7c2b7$126dd4e0$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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: > > << > Most variants that share a prefix are mutually exclusive. For example, > the German orthographic variations '1996' and '1901' SHOULD NOT be used > in the same tag, as they represent the dates of different spelling > reforms. A variant that can meaningfully be used in combination with > another variant SHOULD include a 'Prefix' field in its registry record > that lists that other variant. For example, if another German variant > 'example' were created that made sense to use with '1996', then > 'example' should include two Prefix fields: "de" and "de-1996". >>> > > A human can easily see that "de-1901-1996" and "sl-rozaj-njiva" are > meaningless, because the variants are clearly contradictory. But a few > variants with the same prefix can in fact be used together, such as > "en-scouse-fonipa" or "en-boont-fonipa". Uh... fonipa has no prefix, so it doesn't share a prefix with either scouse or boont. In fact, 'fonipa' and 'fonupa' > have no prefix and can thus theoretically be used with any tag, but some > combinations like "el-monoton-fonipa" are inappropriate nonetheless. Yep. We have no mechanism for saying this. This would fall under the rubric of "Tag Content Wisely" > > At http://users.adelphia.net/~dewell/prefix-anomaly.html you can find an > illustration of this situation. The drop-down list of variant subtags > for "sl-rozaj" shows not only the reasonable choices, like 'fonipa' (no > prefix) and 'njiva' (prefix = "sl-rozaj"), but also the inappropriate > 'nedis' (prefix = "sl"). Ur... nedis and rozaj share a prefix and thus fall under the general exclusion rule. > > What information is available in either RFC 4646(bis) or in the Registry > that would help software to make this decision? Does a prefix of > "language with no variant" mean that the variant should not be used in > the presence of any other variant? That is, in fact, what the RFC says. How else should we interpret: > Most variants that share a prefix are mutually exclusive. How does one determine that > "en-scouse-fonipa" is OK while "el-monoton-fonipa" is not? Not via Prefixes. I'll note that "el-AQ-monoton" is also a dubious choice. There is an upper limit to the amount of information we can pack into the registry, I think. We could add the following text after the quoted paragraph though: -- Some variants have no Prefix or have several different primary language prefixes. Such variants might be useful in combination with other, similar variants or with variants specific to a given language. This isn't always true and care is called for in selecting between these subtags. For example, a tag like "el-monoton-fonipa" is probably ill-considered, since both 'monoton' (Monotonic Greek) and 'fonipa' (International Phonetic Alphabet) can't both be used to transcribe the same document at the same time. -- Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 Jul 10 10:35:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Goh-0007B2-Dl; Tue, 10 Jul 2007 10:35:51 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8Gog-0007Ax-Vd for ltru-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 10:35:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Gog-0007Ap-MF for ltru@ietf.org; Tue, 10 Jul 2007 10:35:50 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Gog-0006Sc-CW for ltru@ietf.org; Tue, 10 Jul 2007 10:35:50 -0400 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 <20070710143549.WRT26351.mta13.adelphia.net@DGBP7M81>; Tue, 10 Jul 2007 10:35:49 -0400 Message-ID: <008801c7c2ff$9bc58290$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <006501c7c2b7$126dd4e0$6401a8c0@DGBP7M81> <4693850D.3090708@yahoo-inc.com> Date: Tue, 10 Jul 2007 07:35:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Subject: [Ltru] Re: Registry change of the day: prefix with more than one 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 Addison Phillips wrote: >> A human can easily see that "de-1901-1996" and "sl-rozaj-njiva" are >> meaningless, because the variants are clearly contradictory. But a >> few variants with the same prefix can in fact be used together, such >> as "en-scouse-fonipa" or "en-boont-fonipa". > > Uh... fonipa has no prefix, so it doesn't share a prefix with either > scouse or boont. Sorry for being unclear. 'fonipa' does not have a prefix in the Registry, but it does have a prefix when used in actual tags such as "en-scouse-fonipa". >> In fact, 'fonipa' and 'fonupa' have no prefix and can thus >> theoretically be used with any tag, but some combinations like >> "el-monoton-fonipa" are inappropriate nonetheless. > > Yep. We have no mechanism for saying this. This would fall under the > rubric of "Tag Content Wisely" I agree that this is definitely a TCW situation. Perhaps "en-scouse-boont" is also TCW and thus software can't be expected to make the "right" call. >> ... The drop-down list of variant subtags for "sl-rozaj" shows not >> only the reasonable choices, like 'fonipa' (no prefix) and 'njiva' >> (prefix = "sl-rozaj"), but also the inappropriate 'nedis' (prefix = >> "sl"). > > Ur... nedis and rozaj share a prefix and thus fall under the general > exclusion rule. Which is great for TCW. But we may have variants in the future that have the same prefix -- that is, apply to the same language -- but deal with different aspects of "variation." Right now we have variants for orthographies and for dialects. Perhaps someday an alternative orthography will emerge for Armenian, which can be used with either Eastern or Western... you see where I'm headed. >> Does a prefix of "language with no variant" mean that the variant >> should not be used in the presence of any other variant? > > That is, in fact, what the RFC says. How else should we interpret: > >> Most variants that share a prefix are mutually exclusive. Then I hope an alternative orthography for Armenian never emerges. > How does one determine that "en-scouse-fonipa" is OK while > "el-monoton-fonipa" is not? > > Not via Prefixes. I'll note that "el-AQ-monoton" is also a dubious > choice. Not syntactically. The RFC explicitly states that such combinations are doofy but allowable. There is no mechanism and no wording that says "don't do this" as there is with Prefix. > There is an upper limit to the amount of information we can pack into > the registry, I think. No one agrees with that more than me. I'm not looking to add more stuff to the Registry. I'm looking for guidance from the RFC and the list. > We could add the following text after the quoted paragraph though: > > -- > Some variants have no Prefix or have several different primary > language prefixes. Such variants might be useful in combination with > other, similar variants or with variants specific to a given language. > This isn't always true and care is called for in selecting between > these subtags. For example, a tag like "el-monoton-fonipa" is probably > ill-considered, since both 'monoton' (Monotonic Greek) and 'fonipa' > (International Phonetic Alphabet) can't both be used to transcribe the > same document at the same time. > -- That's a good elaboration of TCW. I guess the answer is that I have to allow "nedis" to be chosen even if "rozaj" has already been chosen, but I should mark it as questionable. -- 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 Jul 10 10:38:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8GrS-0000l4-Va; Tue, 10 Jul 2007 10:38:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8GrR-0000kw-Jk for ltru-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 10:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8GrR-0000ko-AI for ltru@ietf.org; Tue, 10 Jul 2007 10:38:41 -0400 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8GrR-0006WO-0E for ltru@ietf.org; Tue, 10 Jul 2007 10:38:41 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1000942nzf for ; Tue, 10 Jul 2007 07:38:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=o/jwbzQGTVatn95J9bGWs8YLGOWtMM+yEwgcRQthvDaNSV67sxa0goqrKRZ9t7T/sVQUhe8xa0ePPpuehlDp7IaikdD75peR+KZRobov188iOcxyt71HKQTnqqd/Yy6UPJSVjS53X1q6nt4Gw3MftXmd6CLTu9NR2HfXT7qh3Bo= 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=X6Vhg8dMoRa3d1k/H/pW7flfSyl/16xOqtnyOBIraxV5LTvAMcU/mZ4yrJoIQTQYYjNEqv2/tHedQMCaYT/eFIfByu1+SpuKwHt21ZqU+cvdGjG9hx8gksQTD64yre8xVYPHGgvOn6h0kp7STHOvJV6Iysy0Mb8TJ0wqVe4iaeM= Received: by 10.114.77.1 with SMTP id z1mr4251291waa.1184078320183; Tue, 10 Jul 2007 07:38:40 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Tue, 10 Jul 2007 07:38:40 -0700 (PDT) Message-ID: <30b660a20707100738o14d49d5era58bd9d2e9ef7376@mail.gmail.com> Date: Tue, 10 Jul 2007 07:38:40 -0700 From: "Mark Davis" To: "Chris Newman" Subject: Re: [Ltru] Resolving issues In-Reply-To: <3A5A0E7C33578AA7170CB186@10.0.1.21> MIME-Version: 1.0 References: <30b660a20706291506jd82e202s8bbc931de10e24b3@mail.gmail.com> <6.0.0.20.2.20070701105325.0ac7b750@localhost> <30b660a20707011732n6bca450aj187400d05d3ba46c@mail.gmail.com> <3A5A0E7C33578AA7170CB186@10.0.1.21> X-Google-Sender-Auth: 77bba359697b76e8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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="===============1176201306==" Errors-To: ltru-bounces@ietf.org --===============1176201306== Content-Type: multipart/alternative; boundary="----=_Part_128919_19527911.1184078320152" ------=_Part_128919_19527911.1184078320152 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I was actually just quoting Martin in my message. The language Addison and I originally suggested was: The IESG will solicit nominees for the position (upon adoption of this document or upon a vacancy) and then solicit feedback on the nominees' qualifications. Qualified candidates should be familiar with BCP 47 and its requirements; be willing to fairly, responsively, and judiciously administer the registration process; and be suitably informed about the issues of language identification so that they can draw upon and assess the claim and contributions of language experts and subtag requesters. Mark On 7/9/07, Chris Newman wrote: > > Mark Davis wrote on 7/1/07 17:32 -0700: > > I think one big issue that isn't dealt with here is that the appointment > > is for an infinite term. I think it would be much better to have a > > limited term (e.g. two years), with a possibility for renewal. > > This gives a good chance for reviewing from both sides (both the > > reviewer as well as the IESG). > > Having to review _every_ expert reviewer every two years would be a > significant > time commitment for the IESG (there are a _lot_ of expert reviewers -- > 100+). > I'd rather apply the "if it's not broken, don't fix it" principle to > expert > reviewers as that's more scalable. If the community has problems with an > expert reviewer, please express those concerns directly to the expert > reviewer > and if that doesn't satisfy, contact an appropriate area director or the > IESG. > > - Chris > > -- Mark ------=_Part_128919_19527911.1184078320152 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I was actually just quoting Martin in my message. The language Addison and I originally suggested was:

The IESG will solicit nominees for the position (upon adoption of this document or upon a vacancy) and then solicit feedback on the nominees' qualifications.

Qualified candidates should be familiar with BCP 47 and its requirements; be willing to fairly, responsively, and judiciously administer the registration process; and be suitably informed about the issues of language identification so that they can draw upon and assess the claim and contributions of language experts and subtag requesters.

Mark

On 7/9/07, Chris Newman < Chris.Newman@sun.com> wrote:
Mark Davis wrote on 7/1/07 17:32 -0700:
> I think one big issue that isn't dealt with here is that the appointment
> is for an infinite term. I think it would be much better to have a
> limited term (e.g. two years), with a possibility for renewal.
> This gives a good chance for reviewing from both sides (both the
> reviewer as well as the IESG).

Having to review _every_ expert reviewer every two years would be a significant
time commitment for the IESG (there are a _lot_ of expert reviewers -- 100+).
I'd rather apply the "if it's not broken, don't fix it" principle to expert
reviewers as that's more scalable.  If the community has problems with an
expert reviewer, please express those concerns directly to the expert reviewer
and if that doesn't satisfy, contact an appropriate area director or the IESG.

                - Chris




--
Mark ------=_Part_128919_19527911.1184078320152-- --===============1176201306== 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 --===============1176201306==-- From ltru-bounces@ietf.org Tue Jul 10 12:21:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ITI-00076i-LJ; Tue, 10 Jul 2007 12:21:52 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8ITH-00073k-6c for ltru-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 12:21:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ITG-00073c-Sh for ltru@ietf.org; Tue, 10 Jul 2007 12:21:50 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8IT1-00010o-KZ for ltru@ietf.org; Tue, 10 Jul 2007 12:21:50 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 10 Jul 2007 09:20:30 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Tue, 10 Jul 2007 09:20:30 -0700 From: Peter Constable To: LTRU Working Group , "ietf-languages@iana.org" Date: Tue, 10 Jul 2007 09:20:28 -0700 Subject: RE: [Ltru] Re: Solving the UTF-8 problem Thread-Topic: [Ltru] Re: Solving the UTF-8 problem Thread-Index: AcfCvQsErhfdYV0HSLC00VLEQmQKQgAUNDvg Message-ID: References: <006501c7bc33$637b08b0$6401a8c0@DGBP7M81> <20070702201555.GA17967@sources.org> <000701c7bd37$65947eb0$6401a8c0@DGBP7M81> <490E048F8E5A21C40359DB47@[10.0.1.21]> In-Reply-To: <490E048F8E5A21C40359DB47@[10.0.1.21]> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: Chris Newman [mailto:Chris.Newman@Sun.COM] > UTF-8 has been the recommend charset for Internet interchange since RFC > 2277. > Our past experience with ASCII encodings of non-ASCII text in the IETF > has been > questionable... Meanwhile, UTF-8 based IETF protocols have been less > problematic from an interoperability viewpoint... Sound to me like good arguments for us to be considering UTF-8 for the LSTR= . Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jul 11 10:03:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cnD-0002Ss-TN; Wed, 11 Jul 2007 10:03:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8cnC-0002Sj-7h for ltru-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 10:03:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cnB-0002Sb-UN for ltru@ietf.org; Wed, 11 Jul 2007 10:03:45 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8cn7-00014P-Eh for ltru@ietf.org; Wed, 11 Jul 2007 10:03:45 -0400 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 11 Jul 2007 15:03:38 +0100 From: "Debbie Garside" To: , "'LTRU Working Group'" , Subject: RE: [Ltru] Re: Solving the UTF-8 problem Date: Wed, 11 Jul 2007 15:03:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcfCvQsErhfdYV0HSLC00VLEQmQKQgAUNDvgAC2L9yA= X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Message-Id: 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 Couldn't we just put it to the vote? I thought we had this discussion a year or so ago? FWIW, my vote would be +1 Best regards Debbie > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: 10 July 2007 17:20 > To: LTRU Working Group; ietf-languages@iana.org > Subject: RE: [Ltru] Re: Solving the UTF-8 problem > > > From: Chris Newman [mailto:Chris.Newman@Sun.COM] > > > > UTF-8 has been the recommend charset for Internet interchange since > > RFC 2277. > > Our past experience with ASCII encodings of non-ASCII text > in the IETF > > has been questionable... Meanwhile, UTF-8 based IETF protocols have > > been less problematic from an interoperability viewpoint... > > Sound to me like good arguments for us to be considering > UTF-8 for the LSTR. > > > > Peter > > > _______________________________________________ > 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 Jul 11 10:13:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cwk-00059e-Uj; Wed, 11 Jul 2007 10:13:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8cwh-00059J-9O for ltru-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 10:13:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cwg-00059A-Vk for ltru@ietf.org; Wed, 11 Jul 2007 10:13:34 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8cwc-0001JE-Il for ltru@ietf.org; Wed, 11 Jul 2007 10:13:34 -0400 Received: from [10.72.76.224] (snvvpn2-10-72-76-c224.corp.yahoo.com [10.72.76.224]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l6BEDISf003060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 07:13:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=nARGfvprKTODTDJFNAuZGzQdWy97gUvzvfSudTILrqzhawFNB/RKAHtQenuv1fju Message-ID: <4694E57E.5030909@yahoo-inc.com> Date: Wed, 11 Jul 2007 07:13:18 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Debbie Garside Subject: Re: [Ltru] Re: Solving the UTF-8 problem 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: f60d0f7806b0c40781eee6b9cd0b2135 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 Voting isn't the measure: rough consensus is the measure. I agree that a strawpoll would help establish if we have consensus, though. I, of course, have always supported putting the registry into UTF-8. If folks are happy with the resolution to the parser compatibility issue, I'm happy to go to UTF-8. So: +1 Addison Debbie Garside wrote: > Couldn't we just put it to the vote? I thought we had this discussion a > year or so ago? > > FWIW, my vote would be +1 > > Best regards > > Debbie > >> -----Original Message----- >> From: Peter Constable [mailto:petercon@microsoft.com] >> Sent: 10 July 2007 17:20 >> To: LTRU Working Group; ietf-languages@iana.org >> Subject: RE: [Ltru] Re: Solving the UTF-8 problem >> >>> From: Chris Newman [mailto:Chris.Newman@Sun.COM] >> >>> UTF-8 has been the recommend charset for Internet interchange since >>> RFC 2277. >>> Our past experience with ASCII encodings of non-ASCII text >> in the IETF >>> has been questionable... Meanwhile, UTF-8 based IETF protocols have >>> been less problematic from an interoperability viewpoint... >> Sound to me like good arguments for us to be considering >> UTF-8 for the LSTR. >> >> >> >> Peter >> >> >> _______________________________________________ >> 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. Chair -- W3C Internationalization Core WG 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 Jul 11 10:24:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8d79-0007oQ-8e; Wed, 11 Jul 2007 10:24:23 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8d78-0007o9-JG for ltru-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 10:24:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8d78-0007nz-9P for ltru@ietf.org; Wed, 11 Jul 2007 10:24:22 -0400 Received: from bay0-omc3-s10.bay0.hotmail.com ([65.54.246.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8d73-0001Zg-UT for ltru@ietf.org; Wed, 11 Jul 2007 10:24:22 -0400 Received: from hotmail.com ([65.54.169.33]) by BAY0-OMC3-S10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 11 Jul 2007 07:24:17 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Jul 2007 07:24:16 -0700 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Wed, 11 Jul 2007 14:24:11 GMT X-Originating-IP: [74.255.101.129] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com In-Reply-To: <200707111403.l6BE3eRE029477@pechora4.lax.icann.org> From: "CE Whitehead" To: ltru@ietf.org, ietf-languages@iana.org Bcc: Subject: RE: [Ltru] Re: Solving the UTF-8 problem Date: Wed, 11 Jul 2007 10:24:11 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 11 Jul 2007 14:24:16.0948 (UTC) FILETIME=[29BC8F40:01C7C3C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, I am also for utf-8 so long as we link to the appropriate fonts/viewers (for libraries). Plus of course I assume we are keeping an unofficial text version at langtag.net --C. E. Whitehead cewcathar@hotmail.com (I'll be off-line for a few days at least--starting tomorrow or next day. As I will be on the road.) _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary!  http://club.live.com/chicktionary.aspx?icid=chick_hotmailtextlink2 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jul 11 13:03:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8fbC-0005yt-Vp; Wed, 11 Jul 2007 13:03:34 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8fbB-0005wY-2s for ltru-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 13:03:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8fbA-0005wM-Ko for ltru@ietf.org; Wed, 11 Jul 2007 13:03:32 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8fb6-0006y7-5S for ltru@ietf.org; Wed, 11 Jul 2007 13:03:32 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Wed, 11 Jul 2007 10:03:18 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Wed, 11 Jul 2007 10:03:17 -0700 From: Peter Constable To: Addison Phillips , Debbie Garside Date: Wed, 11 Jul 2007 10:03:12 -0700 Subject: RE: [Ltru] Re: Solving the UTF-8 problem Thread-Topic: [Ltru] Re: Solving the UTF-8 problem Thread-Index: AcfDxa1rGmkm+izBQbyaGfKbRsTgsgAF6xGg Message-ID: References: <4694E57E.5030909@yahoo-inc.com> In-Reply-To: <4694E57E.5030909@yahoo-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 +1 -----Original Message----- From: Addison Phillips [mailto:addison@yahoo-inc.com] Sent: Wednesday, July 11, 2007 7:13 AM To: Debbie Garside Cc: Peter Constable; 'LTRU Working Group' Subject: Re: [Ltru] Re: Solving the UTF-8 problem Voting isn't the measure: rough consensus is the measure. I agree that a strawpoll would help establish if we have consensus, though. I, of course, have always supported putting the registry into UTF-8. If folks are happy with the resolution to the parser compatibility issue, I'm happy to go to UTF-8. So: +1 Addison Debbie Garside wrote: > Couldn't we just put it to the vote? I thought we had this discussion a > year or so ago? > > FWIW, my vote would be +1 > > Best regards > > Debbie > >> -----Original Message----- >> From: Peter Constable [mailto:petercon@microsoft.com] >> Sent: 10 July 2007 17:20 >> To: LTRU Working Group; ietf-languages@iana.org >> Subject: RE: [Ltru] Re: Solving the UTF-8 problem >> >>> From: Chris Newman [mailto:Chris.Newman@Sun.COM] >> >>> UTF-8 has been the recommend charset for Internet interchange since >>> RFC 2277. >>> Our past experience with ASCII encodings of non-ASCII text >> in the IETF >>> has been questionable... Meanwhile, UTF-8 based IETF protocols have >>> been less problematic from an interoperability viewpoint... >> Sound to me like good arguments for us to be considering >> UTF-8 for the LSTR. >> >> >> >> Peter >> >> >> _______________________________________________ >> 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. Chair -- W3C Internationalization Core WG 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 Jul 11 17:13:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8jVJ-0005ZN-BE; Wed, 11 Jul 2007 17:13:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8jVI-0005U3-CJ for ltru-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 17:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8jVH-0005Sl-LU for ltru@ietf.org; Wed, 11 Jul 2007 17:13:44 -0400 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8jVD-0007kU-77 for ltru@ietf.org; Wed, 11 Jul 2007 17:13:43 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1437655nzf for ; Wed, 11 Jul 2007 14:13:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=l5qOGmf88b8Z/cQ1CzSZETK+R6gijQ4SRefQg0uSiNgjcIy85SRhdJNeBbEhjbP/onn+Y/DM5ojNg6tUgECOQA2c/gX0PAcfHMXl1Chf7h5dZLgRdd3/YWpOpcfvXfO5cZQrk61GwO/8sTcdLq/3Mt3FmhQ4UeuEMWlRW5oOT/o= 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=SjNViSkwZ6/9nTDS99x9gjI+jCUxqDvgiGk8s3nV7HvvjRUg98CtPmjNz5yIHs/cApf6rml74xAhPxWdmdGFXC+s3Wqm46Xn29O+MDdPz1YQzCX96/rTtVhSDETjSvEH6bqFcdPKKVSVQXE86HcRdWgzuaERwtI0YuIcsAvuhoU= Received: by 10.115.49.16 with SMTP id b16mr5466106wak.1184188416454; Wed, 11 Jul 2007 14:13:36 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Wed, 11 Jul 2007 14:13:36 -0700 (PDT) Message-ID: <30b660a20707111413t5cec1d3fs3d6bc83d3852dfa5@mail.gmail.com> Date: Wed, 11 Jul 2007 14:13:36 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: Solving the UTF-8 problem In-Reply-To: MIME-Version: 1.0 References: <4694E57E.5030909@yahoo-inc.com> X-Google-Sender-Auth: 8a7832582a154a48 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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="===============1791491944==" Errors-To: ltru-bounces@ietf.org --===============1791491944== Content-Type: multipart/alternative; boundary="----=_Part_11945_1205825.1184188416216" ------=_Part_11945_1205825.1184188416216 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline +1 On 7/11/07, Peter Constable wrote: > > +1 > > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: Wednesday, July 11, 2007 7:13 AM > To: Debbie Garside > Cc: Peter Constable; 'LTRU Working Group' > Subject: Re: [Ltru] Re: Solving the UTF-8 problem > > Voting isn't the measure: rough consensus is the measure. I agree that a > strawpoll would help establish if we have consensus, though. > > I, of course, have always supported putting the registry into UTF-8. If > folks are happy with the resolution to the parser compatibility issue, > I'm happy to go to UTF-8. > > So: > > +1 > > Addison > > Debbie Garside wrote: > > Couldn't we just put it to the vote? I thought we had this discussion a > > year or so ago? > > > > FWIW, my vote would be +1 > > > > Best regards > > > > Debbie > > > >> -----Original Message----- > >> From: Peter Constable [mailto:petercon@microsoft.com] > >> Sent: 10 July 2007 17:20 > >> To: LTRU Working Group; ietf-languages@iana.org > >> Subject: RE: [Ltru] Re: Solving the UTF-8 problem > >> > >>> From: Chris Newman [mailto:Chris.Newman@Sun.COM] > >> > >>> UTF-8 has been the recommend charset for Internet interchange since > >>> RFC 2277. > >>> Our past experience with ASCII encodings of non-ASCII text > >> in the IETF > >>> has been questionable... Meanwhile, UTF-8 based IETF protocols have > >>> been less problematic from an interoperability viewpoint... > >> Sound to me like good arguments for us to be considering > >> UTF-8 for the LSTR. > >> > >> > >> > >> Peter > >> > >> > >> _______________________________________________ > >> 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. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_11945_1205825.1184188416216 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline +1

On 7/11/07, Peter Constable <petercon@microsoft.com> wrote:
+1

-----Original Message-----
From: Addison Phillips [mailto:addison@yahoo-inc.com]
Sent: Wednesday, July 11, 2007 7:13 AM
To: Debbie Garside
Cc: Peter Constable; 'LTRU Working Group'
Subject: Re: [Ltru] Re: Solving the UTF-8 problem

Voting isn't the measure: rough consensus is the measure. I agree that a
strawpoll would help establish if we have consensus, though.

I, of course, have always supported putting the registry into UTF-8. If
folks are happy with the resolution to the parser compatibility issue,
I'm happy to go to UTF-8.

So:

+1

Addison

Debbie Garside wrote:
> Couldn't we just put it to the vote?  I thought we had this discussion a
> year or so ago?
>
> FWIW, my vote would be +1
>
> Best regards
>
> Debbie
>
>> -----Original Message-----
>> From: Peter Constable [mailto: petercon@microsoft.com]
>> Sent: 10 July 2007 17:20
>> To: LTRU Working Group; ietf-languages@iana.org
>> Subject: RE: [Ltru] Re: Solving the UTF-8 problem
>>
>>> From: Chris Newman [mailto:Chris.Newman@Sun.COM]
>>
>>> UTF-8 has been the recommend charset for Internet interchange since
>>> RFC 2277.
>>> Our past experience with ASCII encodings of non-ASCII text
>> in the IETF
>>> has been questionable... Meanwhile, UTF-8 based IETF protocols have
>>> been less problematic from an interoperability viewpoint...
>> Sound to me like good arguments for us to be considering
>> UTF-8 for the LSTR.
>>
>>
>>
>> Peter
>>
>>
>> _______________________________________________
>> 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.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.


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



--
Mark ------=_Part_11945_1205825.1184188416216-- --===============1791491944== 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 --===============1791491944==-- From ltru-bounces@ietf.org Wed Jul 11 18:48:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8kz1-0000VX-1u; Wed, 11 Jul 2007 18:48:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8kz0-0000VS-F8 for ltru-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 18:48:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8kz0-0000VJ-4c for ltru@ietf.org; Wed, 11 Jul 2007 18:48:30 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8kyw-0002lJ-Uy for ltru@ietf.org; Wed, 11 Jul 2007 18:48:30 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rbfZNOK5+GEZKQAPHFPRN+umh9mGnhwY81SsPY5ETN4vn1+OJRwOFVOKexTAm6Dl; 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 [64.105.136.50] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I8kyV-0007Ft-8H for ltru@ietf.org; Wed, 11 Jul 2007 18:47:59 -0400 Message-ID: <002b01c7c40d$a329e800$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4694E57E.5030909@yahoo-inc.com> <30b660a20707111413t5cec1d3fs3d6bc83d3852dfa5@mail.gmail.com> Subject: Re: [Ltru] Re: Solving the UTF-8 problem Date: Wed, 11 Jul 2007 15:48:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356da05bd9e2d352f1d00896232223c1ce6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.50 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 co-chair... There appears to be an emerging consensus that having UTF-8 in the registry would make sense. Before we can claim to have completed this item, however, we should identify and get agreement on updated text for 4646bis to make it so, as well as any additional instructions for the conversion and "bulk update" of the registry itself. The devil is frequently in the details, so we can't declare consensus here until we've worked throught the rest of the exorcise. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jul 11 19:06:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8lGX-0005AA-0o; Wed, 11 Jul 2007 19:06:37 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8lGW-0005A4-0w for ltru-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 19:06:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8lGV-00059q-L9 for ltru@ietf.org; Wed, 11 Jul 2007 19:06:35 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8lGU-0003DB-Sp for ltru@ietf.org; Wed, 11 Jul 2007 19:06:35 -0400 Received: from c83-248-107-106.bredband.comhem.se ([83.248.107.106]:4543 helo=WGBGKKA02) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.66) (envelope-from ) id 1I8lGL-0006gf-85 for ltru@ietf.org; Thu, 12 Jul 2007 01:06:26 +0200 From: "Kent Karlsson" To: "'LTRU Working Group'" References: <4694E57E.5030909@yahoo-inc.com> <30b660a20707111413t5cec1d3fs3d6bc83d3852dfa5@mail.gmail.com> Subject: RE: [Ltru] Re: Solving the UTF-8 problem Date: Thu, 12 Jul 2007 01:05:32 +0200 Message-ID: <000001c7c410$198b0310$6a6bf853@streamserve.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <30b660a20707111413t5cec1d3fs3d6bc83d3852dfa5@mail.gmail.com> Thread-Index: AcfEAGGbpEtUn5/0TCuSXVo2THTtKgAApCMg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Originating-IP: 83.248.107.106 X-Scan-Result: No virus found in message 1I8lGL-0006gf-85. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1I8lGL-0006gf-85 995a28d721158ddc226ece251b1b3742 X-Spam-Score: 2.8 (++) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0493260941==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0493260941== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C7C420.DD13D310" This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C7C420.DD13D310 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit +1 _____ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Wednesday, July 11, 2007 11:14 PM To: Peter Constable Cc: LTRU Working Group Subject: Re: [Ltru] Re: Solving the UTF-8 problem +1 On 7/11/07, Peter Constable wrote: +1 -----Original Message----- From: Addison Phillips [mailto:addison@yahoo-inc.com] Sent: Wednesday, July 11, 2007 7:13 AM To: Debbie Garside Cc: Peter Constable; 'LTRU Working Group' Subject: Re: [Ltru] Re: Solving the UTF-8 problem Voting isn't the measure: rough consensus is the measure. I agree that a strawpoll would help establish if we have consensus, though. I, of course, have always supported putting the registry into UTF-8. If folks are happy with the resolution to the parser compatibility issue, I'm happy to go to UTF-8. So: +1 Addison Debbie Garside wrote: > Couldn't we just put it to the vote? I thought we had this discussion a > year or so ago? > > FWIW, my vote would be +1 > > Best regards > > Debbie > >> -----Original Message----- >> From: Peter Constable [mailto: petercon@microsoft.com] >> Sent: 10 July 2007 17:20 >> To: LTRU Working Group; ietf-languages@iana.org >> Subject: RE: [Ltru] Re: Solving the UTF-8 problem >> >>> From: Chris Newman [mailto:Chris.Newman@Sun.COM] >> >>> UTF-8 has been the recommend charset for Internet interchange since >>> RFC 2277. >>> Our past experience with ASCII encodings of non-ASCII text >> in the IETF >>> has been questionable... Meanwhile, UTF-8 based IETF protocols have >>> been less problematic from an interoperability viewpoint... >> Sound to me like good arguments for us to be considering >> UTF-8 for the LSTR. >> >> >> >> Peter >> >> >> _______________________________________________ >> 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. Chair -- W3C Internationalization Core WG 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_0001_01C7C420.DD13D310 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
+1

From: Mark Davis=20 [mailto:mark.davis@icu-project.org]
Sent: Wednesday, July = 11, 2007=20 11:14 PM
To: Peter Constable
Cc: LTRU Working=20 Group
Subject: Re: [Ltru] Re: Solving the UTF-8=20 problem

+1

On 7/11/07, Peter=20 Constable <petercon@microsoft.com>=20 wrote:
+1

-----Original=20 Message-----
From: Addison Phillips [mailto:addison@yahoo-inc.com]
Sent:= =20 Wednesday, July 11, 2007 7:13 AM
To: Debbie Garside
Cc: Peter=20 Constable; 'LTRU Working Group'
Subject: Re: [Ltru] Re: Solving = the=20 UTF-8 problem

Voting isn't the measure: rough consensus is = the=20 measure. I agree that a
strawpoll would help establish if we have = consensus, though.

I, of course, have always supported = putting the=20 registry into UTF-8. If
folks are happy with the resolution to = the=20 parser compatibility issue,
I'm happy to go to=20 UTF-8.

So:

+1

Addison

Debbie Garside=20 wrote:
> Couldn't we just put it to the vote?  I = thought we=20 had this discussion a
> year or so ago?
>
> FWIW, = my vote=20 would be +1
>
> Best regards
>
>=20 Debbie
>
>> -----Original Message-----
>> = From:=20 Peter Constable [mailto:=20 petercon@microsoft.com]
>> Sent: 10 July 2007 = 17:20
>>=20 To: LTRU Working Group; ietf-languages@iana.org
&g= t;>=20 Subject: RE: [Ltru] Re: Solving the UTF-8 problem=20
>>
>>> From: Chris Newman [mailto:Chris.Newman@Sun.COM]
>>= ;
>>>=20 UTF-8 has been the recommend charset for Internet interchange=20 since
>>> RFC 2277.
>>> Our past experience = with=20 ASCII encodings of non-ASCII text
>> in the = IETF
>>>=20 has been questionable... Meanwhile, UTF-8 based IETF protocols=20 have
>>> been less problematic from an interoperability=20 viewpoint...
>> Sound to me like good arguments for us to = be=20 considering
>> UTF-8 for the=20 LSTR.
>>
>>
>>
>>=20 Peter
>>
>>
>>=20 _______________________________________________
>> Ltru = mailing=20 list
>> Ltru@ietf.org
>> https://www1.ietf.or= g/mailman/listinfo/ltru
>>
>>
>
>
&g= t;
>
>
>=20 _______________________________________________
> Ltru mailing = list
> Ltru@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/ltru

--
Addison=20 Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C=20 Internationalization Core WG

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


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



--
Mark=20 ------=_NextPart_000_0001_01C7C420.DD13D310-- --===============0493260941== 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 --===============0493260941==-- From ltru-bounces@ietf.org Wed Jul 11 19:13:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8lNO-0005CR-66; Wed, 11 Jul 2007 19:13:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8lNN-0005CE-19 for ltru-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 19:13:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8lNM-0005C6-Ni for ltru@ietf.org; Wed, 11 Jul 2007 19:13:40 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8lNI-0002Ip-AO for ltru@ietf.org; Wed, 11 Jul 2007 19:13:40 -0400 Received: from [10.72.73.3] (snvvpn1-10-72-73-c3.corp.yahoo.com [10.72.73.3]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l6BNDTIb057954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 16:13:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=D6PuA/GeLenGzTNhWeHBCtF0toF8PAtLgtbf3ADKi41aDrQcXwABZLKO+8HUz3F3 Message-ID: <46956417.5030509@yahoo-inc.com> Date: Wed, 11 Jul 2007 16:13:27 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Re: Solving the UTF-8 problem References: <4694E57E.5030909@yahoo-inc.com> <30b660a20707111413t5cec1d3fs3d6bc83d3852dfa5@mail.gmail.com> <002b01c7c40d$a329e800$6601a8c0@oemcomputer> In-Reply-To: <002b01c7c40d$a329e800$6601a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 > The devil is frequently in the details, so we can't declare > consensus here until we've worked throught the rest of the exorcise. Understandable, although, pace any showstoppers, the question currently is whether there is consensus toward pursuing this course. Here's my thought on "order of battle": I will prepare the current text and submit it tomorrow. Then I will incorporate the various pending bits of text plus the necessary changes for UTF-8 into a new prototype draft, which I will publish on inter-locale.com. When the ID Editors publish the draft mentioned just above, I'll submit this new draft. Given their recent history of prompt action, this could even be sometime Friday. This would give us a basis for diff comparisons [and XML2RFC source] (in case we decide to revert Yet One More Time). Since I've already done this exercise once, it shouldn't prove to be that difficult. NB> Doug will need to add instructions in 4645 about how he's converting hex escapes in the original registry to Unicode. Addison Randy Presuhn wrote: > Hi - > > As a co-chair... > > There appears to be an emerging consensus that having UTF-8 in the > registry would make sense. Before we can claim to have completed > this item, however, we should identify and get agreement on updated > text for 4646bis to make it so, as well as any additional > instructions for the conversion and "bulk update" of the registry > itself. The devil is frequently in the details, so we can't declare > consensus here until we've worked throught the rest of the exorcise. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 Jul 11 19:31:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8leE-0001mA-99; Wed, 11 Jul 2007 19:31:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8leC-0001c6-Vq for ltru-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 19:31:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8leC-0001Y2-HQ for ltru@ietf.org; Wed, 11 Jul 2007 19:31:04 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8ldx-0004AI-A9 for ltru@ietf.org; Wed, 11 Jul 2007 19:31:04 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I8ldP-0005Pp-Ni; Wed, 11 Jul 2007 19:30:15 -0400 Date: Wed, 11 Jul 2007 19:30:15 -0400 To: Addison Phillips Subject: Re: [Ltru] Re: Solving the UTF-8 problem Message-ID: <20070711233015.GS24331@mercury.ccil.org> References: <30b660a20707111413t5cec1d3fs3d6bc83d3852dfa5@mail.gmail.com> <002b01c7c40d$a329e800$6601a8c0@oemcomputer> <46956417.5030509@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46956417.5030509@yahoo-inc.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Then I will incorporate the various pending bits of text plus the > necessary changes for UTF-8 into a new prototype draft, Since UTF-8 is controversial and the other bits are (AFAIK) not, please make a separate all-pre-UTF-8 fixes draft. I know this uses up another positive integer as a draft number, but we have lots of those. That way we can focus on just what diffs constitute the UTF-8 change. -- A poetical purist named Cowan [that's me: cowan@ccil.org] Once put the rest of us dowan. [on xml-dev] "Your verse would be sweeter http://www.ccil.org/~cowan If it only had metre And rhymes that didn't force me to frowan." [overpacked line!] --Michael Kay _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Jul 11 21:04:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8n63-00044v-8b; Wed, 11 Jul 2007 21:03:55 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8n62-00044Y-2i for ltru-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 21:03:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8n61-00044O-OQ for ltru@ietf.org; Wed, 11 Jul 2007 21:03:53 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8n5m-0006US-HP for ltru@ietf.org; Wed, 11 Jul 2007 21:03:53 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AokbDsWUrt9SWRc+u3O1IlmfoOWC9A15r07ehJk1kCV0GuvCke3fd5i4ceieq/c7; 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 [64.105.136.50] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I8n5D-0001QB-NB for ltru@ietf.org; Wed, 11 Jul 2007 21:03:03 -0400 Message-ID: <000601c7c420$81ef7520$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20707111413t5cec1d3fs3d6bc83d3852dfa5@mail.gmail.com> <002b01c7c40d$a329e800$6601a8c0@oemcomputer> <46956417.5030509@yahoo-inc.com> <20070711233015.GS24331@mercury.ccil.org> Subject: Re: [Ltru] Re: Solving the UTF-8 problem Date: Wed, 11 Jul 2007 18:03:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356ccefcf3b510eae44206c4cf45d217d15350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.50 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "John Cowan" > To: "Addison Phillips" > Cc: "Randy Presuhn" ; "LTRU Working Group" > Sent: Wednesday, July 11, 2007 4:30 PM > Subject: Re: [Ltru] Re: Solving the UTF-8 problem > > Addison Phillips scripsit: > > > Then I will incorporate the various pending bits of text plus the > > necessary changes for UTF-8 into a new prototype draft, > > Since UTF-8 is controversial and the other bits are (AFAIK) not, > please make a separate all-pre-UTF-8 fixes draft. I know this > uses up another positive integer as a draft number, but we have > lots of those. > > That way we can focus on just what diffs constitute the UTF-8 change. ... Both as a technical contributor and as a co-chair, I like this idea. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jul 12 01:21:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8r7L-0007iZ-At; Thu, 12 Jul 2007 01:21:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8r7J-0007iR-Hj for ltru-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 01:21:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8r7H-0007iI-8I for ltru@ietf.org; Thu, 12 Jul 2007 01:21:27 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8r7G-0006ga-JV for ltru@ietf.org; Thu, 12 Jul 2007 01:21:27 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l6C5K1jc022944 for ; Thu, 12 Jul 2007 14:20:02 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 047e_8a62ca80_3037_11dc_8538_0014221fa3c9; Thu, 12 Jul 2007 14:20:01 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:56697) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 12 Jul 2007 14:17:48 +0900 Message-Id: <6.0.0.20.2.20070712104020.06441050@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 12 Jul 2007 10:42:48 +0900 To: John Cowan , Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Re: Solving the UTF-8 problem In-Reply-To: <20070711233015.GS24331@mercury.ccil.org> References: <30b660a20707111413t5cec1d3fs3d6bc83d3852dfa5@mail.gmail.com> <002b01c7c40d$a329e800$6601a8c0@oemcomputer> <46956417.5030509@yahoo-inc.com> <20070711233015.GS24331@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 The comment below seems to say that changes due to UTF-8 will be all over the place. That should not be the case. Even if they are, it's easy in a consolidated diff to identify what has changed due to UTF-8. I'd propose that the editors look over the draft, and send some proposed text for changes to the list, but that we don't burn another integer (because at the moment, the furnace is closed :-). Regards, Martin. At 08:30 07/07/12, John Cowan wrote: >Addison Phillips scripsit: > >> Then I will incorporate the various pending bits of text plus the >> necessary changes for UTF-8 into a new prototype draft, > >Since UTF-8 is controversial and the other bits are (AFAIK) not, >please make a separate all-pre-UTF-8 fixes draft. I know this >uses up another positive integer as a draft number, but we have >lots of those. > >That way we can focus on just what diffs constitute the UTF-8 change. > > >-- >A poetical purist named Cowan [that's me: cowan@ccil.org] >Once put the rest of us dowan. [on xml-dev] > "Your verse would be sweeter http://www.ccil.org/~cowan > If it only had metre >And rhymes that didn't force me to frowan." [overpacked line!] --Michael Kay > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jul 12 03:13:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8srh-0006gY-1e; Thu, 12 Jul 2007 03:13:29 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8srf-0006gT-Gd for ltru-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 03:13:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8sre-0006gL-OJ for ltru@ietf.org; Thu, 12 Jul 2007 03:13:26 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8sra-0001F1-Em for ltru@ietf.org; Thu, 12 Jul 2007 03:13:26 -0400 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 <20070712071321.NWDY19079.mta11.adelphia.net@DGBP7M81> for ; Thu, 12 Jul 2007 03:13:21 -0400 Message-ID: <005801c7c454$20e0d150$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 12 Jul 2007 00:13:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ltru] Re: Solving the UTF-8 problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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. But you knew 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 Thu Jul 12 04:13:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8tng-0001LX-I7; Thu, 12 Jul 2007 04:13:24 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8tne-0001CL-9D for ltru-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 04:13:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8tnd-00019q-Qp for ltru@ietf.org; Thu, 12 Jul 2007 04:13:21 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8tnZ-0002ik-GU for ltru@ietf.org; Thu, 12 Jul 2007 04:13:21 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 289841C00E9; Thu, 12 Jul 2007 10:13:17 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 23E081C007E; Thu, 12 Jul 2007 10:13:17 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 214F958EBF1; Thu, 12 Jul 2007 10:13:17 +0200 (CEST) Date: Thu, 12 Jul 2007 10:13:17 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20070712081317.GA2479@nic.fr> References: <006501c7c2b7$126dd4e0$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006501c7c2b7$126dd4e0$6401a8c0@DGBP7M81> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.6 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: LTRU Working Group Subject: [Ltru] Re: Registry change of the day: prefix with more than one 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 Mon, Jul 09, 2007 at 10:56:33PM -0700, Doug Ewell wrote a message of 72 lines which said: > I can't think of a clean way to tell software which variants can be > used together and which cannot, I believe that we should handle this case under the general rule "standards cannot prevent every stupid thing": "Validity of a tag is not everything. A tag may be valid and meaningless. This is unavoidable with a generative system like the language subtag mechanism. So, ar-Cyrl-AQ - Arabic written with the cyrillic script, as used in Antarctica - is perfectly valid but should nevertheless be avoided because it has no relationship with the reality." There does not seem to be similar text in 4646bis. Do we think it should be included or is it too paternalistic for readers? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jul 12 04:19:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ttn-0002Gn-GY; Thu, 12 Jul 2007 04:19:43 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I8ttl-0002Gi-SS for ltru-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 04:19:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ttl-0002GU-1h for ltru@ietf.org; Thu, 12 Jul 2007 04:19:41 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8ttg-0002qB-OC for ltru@ietf.org; Thu, 12 Jul 2007 04:19:41 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 5B42D1C00EE; Thu, 12 Jul 2007 10:19:36 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 55F1E1C007E; Thu, 12 Jul 2007 10:19:36 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 486CE58EBF1; Thu, 12 Jul 2007 10:19:36 +0200 (CEST) Date: Thu, 12 Jul 2007 10:19:36 +0200 From: Stephane Bortzmeyer To: CE Whitehead Message-ID: <20070712081936.GA6271@nic.fr> References: <200707111403.l6BE3eRE029477@pechora4.lax.icann.org> 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.18-4-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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ietf-languages@iana.org, ltru@ietf.org Subject: [Ltru] Re: Solving the UTF-8 problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Jul 11, 2007 at 10:24:11AM -0400, CE Whitehead wrote a message of 22 lines which said: > Plus of course I assume we are keeping an unofficial text version at > langtag.net You mean an unofficial ASCII version? (UTF-8 is plain text, too, remember this is a discussion about UTF-8, not about XML or JSON) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jul 12 10:52:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I901h-0004wk-Gr; Thu, 12 Jul 2007 10:52:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I901g-0004vE-Nk for ltru-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 10:52:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I901f-0004tJ-UC for ltru@ietf.org; Thu, 12 Jul 2007 10:52:16 -0400 Received: from bay0-omc2-s28.bay0.hotmail.com ([65.54.246.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I901b-0004nq-JL for ltru@ietf.org; Thu, 12 Jul 2007 10:52:15 -0400 Received: from hotmail.com ([65.54.169.47]) by bay0-omc2-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 12 Jul 2007 07:52:11 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Jul 2007 07:52:11 -0700 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Thu, 12 Jul 2007 14:52:08 GMT X-Originating-IP: [74.255.101.129] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com In-Reply-To: <20070712081936.GA6271@nic.fr> From: "CE Whitehead" To: ltru@ietf.org, ietf-languages@iana.org Bcc: Date: Thu, 12 Jul 2007 10:52:08 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 12 Jul 2007 14:52:11.0060 (UTC) FILETIME=[39FF8740:01C7C494] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Ltru] Re: Solving the UTF-8 problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 bortzmeyer at nic.fr wrote: > >On Wed, Jul 11, 2007 at 10:24:11AM -0400, > CE Whitehead wrote > a message of 22 lines which said: > > > Plus of course I assume we are keeping an unofficial text version at > > langtag.net > >You mean an unofficial ASCII version? (UTF-8 is plain text, too, >remember this is a discussion about UTF-8, not about XML or JSON) ACII or ANSI? (ASCII is just basic Latin, right, so the accented characters will not display; for Latin-1 you need ANSI) --C. E. Whitehead cewcathar@hotmail.com _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary!  http://club.live.com/chicktionary.aspx?icid=chick_hotmailtextlink2 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jul 12 11:53:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90zP-0001Wd-4i; Thu, 12 Jul 2007 11:53:59 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I90z8-0001Sb-8A for ltru-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 11:53:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90z7-0001ST-Uq for ltru@ietf.org; Thu, 12 Jul 2007 11:53:41 -0400 Received: from mta5.adelphia.net ([68.168.78.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I90z3-0006lV-KF for ltru@ietf.org; Thu, 12 Jul 2007 11:53:41 -0400 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 <20070712145447.CEEX5501.mta16.adelphia.net@DGBP7M81> for ; Thu, 12 Jul 2007 10:54:47 -0400 Message-ID: <006c01c7c494$96ed3380$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 12 Jul 2007 07:54:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ltru] Re: Solving the UTF-8 problem X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > There appears to be an emerging consensus that having UTF-8 in the > registry would make sense. Before we can claim to have completed this > item, however, we should identify and get agreement on updated text > for 4646bis to make it so, as well as any additional instructions for > the conversion and "bulk update" of the registry itself. I agree, though I don't think it will be hard to figure out which changes are related to UTF-8 and which are not. I am waiting for three things before I can update draft-ietf-ltru-4645bis-01, which is set to expire in less than a week: 1. The results of the current round of changes to ISO 639-3, scheduled to be published in the next few days. 2. A resolution on the question of whether to use extlangs or not. 3. A resolution on the UTF-8 question. While I can issue more than one draft in succession, just as Addison and Mark can, it seems we ought to be able to address these last few issues soon, considering that our charter page still has both drafts scheduled to go to IETF Last Call by January 2007. > The devil is frequently in the details, so we can't declare consensus > here until we've worked throught the rest of the exorcise. At which point we can exorcise the devil? -- 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 Thu Jul 12 14:23:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93Jx-0007m8-9O; Thu, 12 Jul 2007 14:23:21 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I93Ju-0007lk-Tv for ltru-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 14:23:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93Ju-0007lX-89 for ltru@ietf.org; Thu, 12 Jul 2007 14:23:18 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I93Jf-0003AN-09 for ltru@ietf.org; Thu, 12 Jul 2007 14:23:18 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Kf0qXunRZkClfOKGw8J3/gZV4j/u3c3ODQAtq+MW8VCCaaoDF+l1h82jVw2S5KAS; 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 [64.105.136.199] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I93J8-00009v-7Z for ltru@ietf.org; Thu, 12 Jul 2007 14:22:30 -0400 Message-ID: <003001c7c4b1$b73f8f80$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: Solving the UTF-8 problem Date: Thu, 12 Jul 2007 11:23:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a935651b18579094da989f67383562a76b1fa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.199 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "CE Whitehead" > To: ; > Sent: Thursday, July 12, 2007 7:52 AM > Subject: [Ltru] Re: Solving the UTF-8 problem ... > ACII or ANSI? (ASCII is just basic Latin, right, so the accented characters > will not display; for Latin-1 you need ANSI) ... As a technical contributor: The American National Standards Institute (ANSI) is not a character set. The IETF's BCP0018 has been in place for a *long* time, and it makes sense to employ its recommendation: use UTF-8. I've spent a fair amount of time using the computing facilities available to the general public in a small sampling of third-world countries. I've had no problem displaying UTF-8. Tools and appropriate fonts (on ancient and under-powered recycled machines) have not been a problem. Perhaps others' experience is different, but I have little sympathy for claims that appropriate tools are unavailable to the developers who would be using this data. If your public library's computing facilities are not on a par with a typical third-world internet cafe, then you have a problem more critical to your community than the encoding of an IANA registry. (Think globally, act locally?) If someone wants to provide "added value" (or would it be "reduced value"?) versions of the registry contents, that's *their* perogative, but I think we should not be spending our time and energy defining what those (by definition out of our scope) projects might do. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Jul 12 14:27:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93Ny-0000Ly-KC; Thu, 12 Jul 2007 14:27:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I93Nx-0000Lq-WA for ltru-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 14:27:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93Nx-0000Lc-MQ for ltru@ietf.org; Thu, 12 Jul 2007 14:27:29 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I93Nt-0008Ry-AY for ltru@ietf.org; Thu, 12 Jul 2007 14:27:29 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=sGWNhT7E6ez2RgS9EOJQtzz5oJp9t9u11sQ7vOTm0tIxtKrVbWF9KUPC/fEQtIC6; 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 [64.105.136.199] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I93Ns-0002FF-I9 for ltru@ietf.org; Thu, 12 Jul 2007 14:27:24 -0400 Message-ID: <003901c7c4b2$67721120$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <006501c7c2b7$126dd4e0$6401a8c0@DGBP7M81> <20070712081317.GA2479@nic.fr> Subject: Re: [Ltru] Re: Registry change of the day: prefix with more than onesubtag Date: Thu, 12 Jul 2007 11:28:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a9356cc2ef8990a97af30560b17c48f699a4f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.199 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Doug Ewell" > Cc: "LTRU Working Group" > Sent: Thursday, July 12, 2007 1:13 AM > Subject: [Ltru] Re: Registry change of the day: prefix with more than onesubtag > > On Mon, Jul 09, 2007 at 10:56:33PM -0700, > Doug Ewell wrote > a message of 72 lines which said: > > > I can't think of a clean way to tell software which variants can be > > used together and which cannot, > > I believe that we should handle this case under the general rule > "standards cannot prevent every stupid thing": > > "Validity of a tag is not everything. A tag may be valid and > meaningless. This is unavoidable with a generative system like the > language subtag mechanism. So, ar-Cyrl-AQ - Arabic written with the > cyrillic script, as used in Antarctica - is perfectly valid but should > nevertheless be avoided because it has no relationship with the > reality." > > There does not seem to be similar text in 4646bis. Do we think it > should be included or is it too paternalistic for readers? Since the question seems to keep coming up, it's probably worth including. For a heading for the section, I like your words: "standards cannot prevent every stupid thing." I'd suggest putting it next to the section entitled "tag wisely." :-) * 0.5 Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jul 13 15:02:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9QOt-0007F2-20; Fri, 13 Jul 2007 15:01:59 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I9QOr-0007Eo-Uc for ltru-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 15:01:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9QOr-0007Ee-JT for ltru@ietf.org; Fri, 13 Jul 2007 15:01:57 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9QOr-0005YF-7e for ltru@ietf.org; Fri, 13 Jul 2007 15:01:57 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l6DIxXdt095618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 11:59:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=T84vxOglsHL9jeBqJYCvthwXjRzZq6m/sHtoffSU56fxYFeZdcULz9ZNWCy+l4L3 Message-ID: <4697CB95.2010501@yahoo-inc.com> Date: Fri, 13 Jul 2007 11:59:33 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Suggested text for future compatibility of registry processors. References: <30b660a20707011618m67fe32e6n73e81f8d3bddd69d@mail.gmail.com> In-Reply-To: <30b660a20707011618m67fe32e6n73e81f8d3bddd69d@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 While catching up on my backlog I notice the following note from Mark. I would note that we already have a shorter equivalent of this text at the end of 3.1.2, where it says: -- Future versions of this document might add additional fields to the registry, so implementations SHOULD ignore fields found in the registry that are not defined in this document. -- This text was apparently added back in draft-02. Any reason to edit it some more? Addison Mark Davis wrote: > Doug noted the following in his email on UTF-8 (on which topic I agree with > him, btw). > >> Addison is correct; any structural change to the Registry will break RFC > 4646-conformant processors. This is true not only for UTF-8, but also for > new fields such as "Macrolanguage" or "Modified." (Section 3.1 says the > Type "MUST" be one of the seven currently defined values.) > > I suggest that we add language to 4646bis noting this, with the following > suggested text. > > Add to the end of 3.1.2. Record Definitions: > > Future versions of the language subtag registry may add more fields. > Processors of the registry that are not intended to be updated with each > successive version of BCP 47 and thus need to be compatible with future > versions of the registry, SHOULD be written so as to ignore additional > fields. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Jul 13 15:10:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9QWr-0001bq-Sa; Fri, 13 Jul 2007 15:10:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I9QWq-0001bf-T0 for ltru-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 15:10:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9QWq-0001bS-HO for ltru@ietf.org; Fri, 13 Jul 2007 15:10:12 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9QWl-0003rE-Lq for ltru@ietf.org; Fri, 13 Jul 2007 15:10:12 -0400 Received: by wa-out-1112.google.com with SMTP id k17so819027waf for ; Fri, 13 Jul 2007 12:10:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ZpQl8+/oK7uLjUoOVPkEePr0O7aGpFfBUK80BGtOjKy1bP2B0bXwu/4R5G/rTPBn5BvQyotYwV5NTf+DAhCgEPz4GIPivizlajax/aLD5+unpdRpiEQSXu19N8IWktBpT2vURBFxOS8jIWiTvP6zBpFvJb05sht4lGRz/cZx+fo= 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:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=RozpV5VH7aUD9lKvZ34+LPk8nJWzLK2Kx34h8q5KAlNTmAvOp2TUqtNjybqVi7PcHHLFfBMP2oCNls9NNaZEV6fHEJu4nuo/CopwxOYSldFvpx0P08w8dtbbM74LrtDaiysyDAKm3tRjK9JuFfpWamseKfuHtmh4LcJZmCNqdBo= Received: by 10.114.190.6 with SMTP id n6mr1933228waf.1184353806452; Fri, 13 Jul 2007 12:10:06 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Fri, 13 Jul 2007 12:10:06 -0700 (PDT) Message-ID: <30b660a20707131210n7dccbce8sbee7a31fe7b69ab1@mail.gmail.com> Date: Fri, 13 Jul 2007 12:10:06 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Suggested text for future compatibility of registry processors. In-Reply-To: <4697CB95.2010501@yahoo-inc.com> MIME-Version: 1.0 References: <30b660a20707011618m67fe32e6n73e81f8d3bddd69d@mail.gmail.com> <4697CB95.2010501@yahoo-inc.com> X-Google-Sender-Auth: 9f3fd1dca2eb7d21 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0736243941==" Errors-To: ltru-bounces@ietf.org --===============0736243941== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline wrExCgoodGhhdCBpcywgSSdtIGZpbmUgbGVhdmluZyBpdCB0aGUgd2F5IGl0IGlzLCBidXQgd291 bGRuJ3Qgb2JqZWN0IHRvCmNoYW5naW5nIGVpdGhlcikKCk9uIDcvMTMvMDcsIEFkZGlzb24gUGhp bGxpcHMgPGFkZGlzb25AeWFob28taW5jLmNvbT4gd3JvdGU6Cj4gV2hpbGUgY2F0Y2hpbmcgdXAg b24gbXkgYmFja2xvZyBJIG5vdGljZSB0aGUgZm9sbG93aW5nIG5vdGUgZnJvbSBNYXJrLgo+Cj4g SSB3b3VsZCBub3RlIHRoYXQgd2UgYWxyZWFkeSBoYXZlIGEgc2hvcnRlciBlcXVpdmFsZW50IG9m IHRoaXMgdGV4dCBhdAo+IHRoZSBlbmQgb2YgMy4xLjIsIHdoZXJlIGl0IHNheXM6Cj4KPiAtLQo+ IEZ1dHVyZSB2ZXJzaW9ucyBvZiB0aGlzIGRvY3VtZW50IG1pZ2h0IGFkZCBhZGRpdGlvbmFsIGZp ZWxkcyB0byB0aGUKPiByZWdpc3RyeSwgc28gaW1wbGVtZW50YXRpb25zIFNIT1VMRCBpZ25vcmUg ZmllbGRzIGZvdW5kIGluIHRoZSByZWdpc3RyeQo+IHRoYXQgYXJlIG5vdCBkZWZpbmVkIGluIHRo aXMgZG9jdW1lbnQuCj4gLS0KPgo+IFRoaXMgdGV4dCB3YXMgYXBwYXJlbnRseSBhZGRlZCBiYWNr IGluIGRyYWZ0LTAyLiBBbnkgcmVhc29uIHRvIGVkaXQgaXQKPiBzb21lIG1vcmU/Cj4KPiBBZGRp c29uCj4KPiBNYXJrIERhdmlzIHdyb3RlOgo+ID4gRG91ZyBub3RlZCB0aGUgZm9sbG93aW5nIGlu IGhpcyBlbWFpbCBvbiBVVEYtOCAob24gd2hpY2ggdG9waWMgSSBhZ3JlZSB3aXRoCj4gPiBoaW0s IGJ0dykuCj4gPgo+ID4+IEFkZGlzb24gaXMgY29ycmVjdDsgYW55IHN0cnVjdHVyYWwgY2hhbmdl IHRvIHRoZSBSZWdpc3RyeSB3aWxsIGJyZWFrIFJGQwo+ID4gNDY0Ni1jb25mb3JtYW50IHByb2Nl c3NvcnMuICBUaGlzIGlzIHRydWUgbm90IG9ubHkgZm9yIFVURi04LCBidXQgYWxzbyBmb3IKPiA+ IG5ldyBmaWVsZHMgc3VjaCBhcyAiTWFjcm9sYW5ndWFnZSIgb3IgIk1vZGlmaWVkLiIgIChTZWN0 aW9uIDMuMSBzYXlzIHRoZQo+ID4gVHlwZSAiTVVTVCIgYmUgb25lIG9mIHRoZSBzZXZlbiBjdXJy ZW50bHkgZGVmaW5lZCB2YWx1ZXMuKQo+ID4KPiA+IEkgc3VnZ2VzdCB0aGF0IHdlIGFkZCBsYW5n dWFnZSB0byA0NjQ2YmlzIG5vdGluZyB0aGlzLCB3aXRoIHRoZSBmb2xsb3dpbmcKPiA+IHN1Z2dl c3RlZCB0ZXh0Lgo+ID4KPiA+IEFkZCB0byB0aGUgZW5kIG9mIDMuMS4yLiAgUmVjb3JkIERlZmlu aXRpb25zOgo+ID4KPiA+IEZ1dHVyZSB2ZXJzaW9ucyBvZiB0aGUgbGFuZ3VhZ2Ugc3VidGFnIHJl Z2lzdHJ5IG1heSBhZGQgbW9yZSBmaWVsZHMuCj4gPiBQcm9jZXNzb3JzIG9mIHRoZSByZWdpc3Ry eSB0aGF0IGFyZSBub3QgaW50ZW5kZWQgdG8gYmUgdXBkYXRlZCB3aXRoIGVhY2gKPiA+IHN1Y2Nl c3NpdmUgdmVyc2lvbiBvZiBCQ1AgNDcgYW5kIHRodXMgbmVlZCB0byBiZSBjb21wYXRpYmxlIHdp dGggZnV0dXJlCj4gPiB2ZXJzaW9ucyBvZiB0aGUgcmVnaXN0cnksIFNIT1VMRCBiZSB3cml0dGVu IHNvIGFzIHRvIGlnbm9yZSBhZGRpdGlvbmFsCj4gPiBmaWVsZHMuCj4gPiA8aHR0cDovL3dpa2kv TWFpbi9JSUlPYmplY3RpdmVzPgo+ID4KPiA+Cj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+Cj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gTHRydSBt YWlsaW5nIGxpc3QKPiA+IEx0cnVAaWV0Zi5vcmcKPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2x0cnUKPgo+IC0tCj4gQWRkaXNvbiBQaGlsbGlwcwo+IEdsb2JhbGl6 YXRpb24gQXJjaGl0ZWN0IC0tIFlhaG9vISBJbmMuCj4gQ2hhaXIgLS0gVzNDIEludGVybmF0aW9u YWxpemF0aW9uIENvcmUgV0cKPgo+IEludGVybmF0aW9uYWxpemF0aW9uIGlzIGFuIGFyY2hpdGVj dHVyZS4KPiBJdCBpcyBub3QgYSBmZWF0dXJlLgo+CgoKLS0gCk1hcmsK --===============0736243941== 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 --===============0736243941==-- From ltru-bounces@ietf.org Fri Jul 13 21:06:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9W5K-0000zd-Us; Fri, 13 Jul 2007 21:06:10 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I9W5J-0000s2-Hk for ltru-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 21:06:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9W5I-0000or-Pd for ltru@ietf.org; Fri, 13 Jul 2007 21:06:08 -0400 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9W5E-0007VT-13 for ltru@ietf.org; Fri, 13 Jul 2007 21:06:08 -0400 Received: by wa-out-1112.google.com with SMTP id k17so914721waf for ; Fri, 13 Jul 2007 18:06:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=ML5AyyrofsZIxyaffFhqUZeWJ+jwV/2lr0nT0tM1skbhBRdlejL7MuxfiqZCNyLn8u8aWUbN3SrwaPlaCtaEW6sIRlYBJzWfyVPoNm9V9WqMjSjoIvsWnL7bORYtqOgUVrUHkwkA8MJd4FACZjvQx2kA9rvYQgEzLzVfklA2LM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=JEhZw2s2CLluogp4knlgAj5OwwJyMSPrMhH+4moZ3f69YcqMoKmC2xA/frEpG5FS/XZos8MVmgd7NwGOrcWJbhNz7jHU0PBeELqeAD4vkyjJ9oK2X/ExoyB9yIyvggiJjSS/+LGj/et+fRj8y5pVOm6S0RqOdCf/woQ54VNfNLw= Received: by 10.115.23.12 with SMTP id a12mr2141665waj.1184375163321; Fri, 13 Jul 2007 18:06:03 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Fri, 13 Jul 2007 18:06:03 -0700 (PDT) Message-ID: <30b660a20707131806o19919cc7v97cc82f3eada43ff@mail.gmail.com> Date: Fri, 13 Jul 2007 18:06:03 -0700 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: 161503b4f10a478f X-Spam-Score: 0.3 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Subject: [Ltru] Macrolanguage and extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1523894569==" Errors-To: ltru-bounces@ietf.org --===============1523894569== Content-Type: multipart/alternative; boundary="----=_Part_44388_23336235.1184375163305" ------=_Part_44388_23336235.1184375163305 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Addision and I have discussed the issue of extlang and Macrolanguages and are proposing the following text replacing the use of extlang. *[A new section called Macrolanguages: ]* The Macrolanguage field contains a primary language subtag that *encompasses * this subtag. That is, this language is a dialect or sub-language of the Macrolanguage, and is called an *encompassed* subtag. The Macrolanguage value is defined by ISO 639-3. The field can be useful to applications or users when selecting language tags or as additional metadata useful in matching. The Macrolanguage field can only occur in records of type 'language'. Only values assigned by ISO 639-3 will be considered for inclusion. Macrolanguage fields MAY be added via the normal registration process whenever ISO 639-3 defines new values. Macrolanguages are informational, and MAY be removed or changed if ISO 639-3 changes the values. For example, the language subtags 'nb' (Norwegian Bokmal) and 'nn' (Norwegian Nynorsk) has a Macrolanguage entry of 'no' (Norwegian). For more information see [Choice]. *[A new section in tag choice (section 4.1), referenced from the above] * Languages with a Macrolanguage field in the registry sometimes can be usefully referenced using their Macrolanguage. However, the Macrolanguage field doesn't define what the relationship is between the language subtag whose record it appears in and its encompassed language or languages. Nor does it define how the encompassed languages are related to one-another. In some cases, the Macrolanguage has a standard form as well as a variety of less-common dialects. For example, the Macrolanguage 'ar' (Arabic) and the subtag 'arb' (Standard Arabic) generally describe the same language, with other subtags describing less-common local variations. In other cases there is no particular standard form and the encompassed subtags describe specific variations within the parent language. Applications MAY use Macrolanguage information to improve matching or language negotiation. For example, the information that 'sr' and 'hr' share a Macrolanguage expresses a closer relation between those languages than between, say, "sr" and "ma" (Macedonian). It is valid to use either the encompassed language or its Macrolanguage to form language tags. However, many matching applications will not be aware of the relationship between the languages. Care in selecting which subtags are used is crucial to interoperability. In general, use the most specific tag. However, where the standard written form of an encompassed language is captured by the Macrolanguage, the Macrolanguage should still be used for written material. In particular, chinese language(s) and dialects call for special consideration. Because the written form is very similar for most languages having 'zh' as a Macrolanguage (and because historically subtags for the various sub-languages and dialects were not available), languages such as 'yue' (Cantonese) have usually used tags beginning with the subtag 'zh'. This past practice of tagging means that Macrolanguage information is encouraged when searching for content or when providing fallbacks in language negotiation. For example, the information that 'yue' has a macrolangauge of 'zh' could be used in the Lookup algorithm to fallback from a request for "yue-Hans-CN" to "zh-Hans-CN" without losing the script and region information (even though the user did not specify "zh-Hans-CN" in their language priority list). However, the Macrolanguage is only one of many additional pieces of information that can be used in matching languages. There are many other circumstances where the "best fit" information is not contained in the language registry. For example, the languages "ro" (Romanian) and "mo" (Moldavian) are very closely related, and so for searching it is often best to treat them as being the same. In other cases, the best fallback for a requested language may be a completely unrelated language, but one that a majority of speakers in the requested language may understand. For example, in a given application the best fallback for "be" (Breton), may be "fr" (French) -- rather than the more closely related "cy" (Welsh) -- because Breton readers are far more likely to be able to read French than Welsh. For more information on matching, see [RFC 4647]. *[In the section talking about updates]* The Macrolanguage field is added whenever a language has a corresponding Macrolanguage in [ISO 639-3]. For example, 'sr' (Serbian) will have the Macrolanguage value 'sh' (Serbo-Croatian). *[Other changes]* [Search for instances of "Suppress-Script" (just as a place to find where field descriptions are) and make an addition of "Macrolanguage" if appropriate, eg in the "LANGUAGE SUBTAG REGISTRATION FORM"] -- Mark ------=_Part_44388_23336235.1184375163305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Addision and I have discussed the issue of extlang and Macrolanguages and are proposing the following text replacing the use of extlang.

[A new section called Macrolanguages: ]

The Macrolanguage field contains a primary language subtag that encompasses this subtag. That is, this language is a dialect or sub-language of the Macrolanguage, and is called an encompassed subtag. The Macrolanguage value is defined by ISO 639-3. The field can be useful to applications or users when selecting language tags or as additional metadata useful in matching. The Macrolanguage field can only occur in records of type 'language'. Only values assigned by ISO 639-3 will be considered for inclusion. Macrolanguage fields MAY be added via the normal registration process whenever ISO 639-3 defines new values. Macrolanguages are informational, and MAY be removed or changed if ISO 639-3 changes the values.

For example, the language subtags 'nb' (Norwegian Bokmal) and 'nn' (Norwegian Nynorsk) has a Macrolanguage entry of 'no' (Norwegian). For more information see [Choice].

[A new section in tag choice (section 4.1), referenced from the above]

Languages with a Macrolanguage field in the registry sometimes can be usefully referenced using their Macrolanguage. However, the Macrolanguage field doesn't define what the relationship is between the language subtag whose record it appears in and its encompassed language or languages. Nor does it define how the encompassed languages are related to one-another. In some cases, the Macrolanguage has a standard form as well as a variety of less-common dialects. For example, the Macrolanguage 'ar' (Arabic) and the subtag 'arb' (Standard Arabic) generally describe the same language, with other subtags describing less-common local variations. In other cases there is no particular standard form and the encompassed subtags describe specific variations within the parent language.

Applications MAY use Macrolanguage information to improve matching or language negotiation. For example, the information that 'sr' and 'hr' share a Macrolanguage expresses a closer relation between those languages than between, say, "sr" and "ma" (Macedonian). It is valid to use either the encompassed language or its Macrolanguage to form language tags. However, many matching applications will not be aware of the relationship between the languages. Care in selecting which subtags are used is crucial to interoperability. In general, use the most specific tag. However, where the standard written form of an encompassed language is captured by the Macrolanguage, the Macrolanguage should still be used for written material.

In particular, chinese language(s) and dialects call for special consideration. Because the written form is very similar for most languages having 'zh' as a Macrolanguage (and because historically subtags for the various sub-languages and dialects were not available), languages such as 'yue' (Cantonese) have usually used tags beginning with the subtag 'zh'. This past practice of tagging means that Macrolanguage information is encouraged when searching for content or when providing fallbacks in language negotiation. For example, the information that 'yue' has a macrolangauge of 'zh' could be used in the Lookup algorithm to fallback from a request for "yue-Hans-CN" to "zh-Hans-CN" without losing the script and region information (even though the user did not specify "zh-Hans-CN" in their language priority list).

However, the Macrolanguage is only one of many additional pieces of information  that can be used in matching languages. There are many other circumstances where the "best fit" information is not contained in the language registry. For example, the languages "ro" (Romanian) and "mo" (Moldavian) are very closely related, and so for searching it is often best to treat them as being the same. In other cases, the best fallback for a requested language may be a completely unrelated language, but one that a majority of speakers in the requested language may understand. For example, in a given application the best fallback for "be" (Breton), may be "fr" (French) -- rather than the more closely related "cy" (Welsh) -- because Breton readers are far more likely to be able to read French than Welsh.  

For more information on matching, see [RFC 4647].  

[In the section talking about updates]

The Macrolanguage field is added whenever a language has a corresponding Macrolanguage in [ISO 639-3]. For example, 'sr' (Serbian) will have the Macrolanguage value 'sh' (Serbo-Croatian).

[Other changes]

[Search for instances of "Suppress-Script" (just as a place to find where field descriptions are) and make an addition of "Macrolanguage" if appropriate, eg in the "LANGUAGE SUBTAG REGISTRATION FORM"]



--
Mark ------=_Part_44388_23336235.1184375163305-- --===============1523894569== 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 --===============1523894569==-- From ltru-bounces@ietf.org Sat Jul 14 08:26:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9ghn-0006KU-Qk; Sat, 14 Jul 2007 08:26:35 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I9ghm-0006KI-V0 for ltru-confirm+ok@megatron.ietf.org; Sat, 14 Jul 2007 08:26:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9ghm-0006K7-JP for ltru@ietf.org; Sat, 14 Jul 2007 08:26:34 -0400 Received: from 113166.kabissa.org ([72.32.199.201] helo=kabissa.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9ghh-0007T3-Mv for ltru@ietf.org; Sat, 14 Jul 2007 08:26:34 -0400 Received: (qmail 27735 invoked from network); 14 Jul 2007 07:26:25 -0500 Received: from pool-71-252-33-82.washdc.east.verizon.net (HELO IBM92AA25595C4) (71.252.33.82) by 72.32.229.137 with SMTP; 14 Jul 2007 07:26:24 -0500 From: "Don Osborn" To: "'Mark Davis'" , "'LTRU Working Group'" References: <30b660a20707131806o19919cc7v97cc82f3eada43ff@mail.gmail.com> In-Reply-To: <30b660a20707131806o19919cc7v97cc82f3eada43ff@mail.gmail.com> Subject: RE: [Ltru] Macrolanguage and extlang Date: Sat, 14 Jul 2007 08:26:21 -0400 Message-ID: <001001c7c612$30a30710$91e91530$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcfFsy0cEv6noLBERlqxTmeICHavaQAIaeXw Content-Language: en-us X-Spam-Score: 0.1 (/) X-Scan-Signature: 08582f3b796126054df71137d5cb69f8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1827110673==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1827110673== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C7C5F0.A9916710" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0011_01C7C5F0.A9916710 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mark, Thanks for this update. In reading this over (and trying to see = between the lines) with an eye to implications for many African = languages and macrolanguages, the mention of Romanian/Moldavian seems = particularly relevant, as an example of cases "where the 'best fit' = information is not contained in the language registry." This is an area = to which I hope that experts on African languages who have a familiarity = with tagging isues can be organized to propose amendments to the system = (i.e., ISO 639, which I realize is not the purview of this list, and the = current RFCs). =20 There are also cases where macrolanguages are defined, but a still = somewhat fluid situation wrt standardization makes defining their use = problematic (I've posted previously on some of the issues as I see them, = both on this list and on ietf-languages - such as cases where the = language tag may be less appropriate than the macrolanguage tag). Here = too there seems to be a need for input by experts on African languages = in discussions of tagging as well as in language planning. =20 In the meantime, I hope that the new wording can accommodate all such = situations, especially for languages with less resources and emerging = standards. =20 The fallback language issue (mentioned in the example re Breton) raises = another question: can there be more than one fallback language? In the = case of many of the crossborder languages in Africa (such as Hausa, = Swahili, Wolof, Fula, Tsonga, Oshiwambo, etc.) this would be helpful. =20 Don =20 =20 =20 From: Mark Davis [mailto:mark.davis@icu-project.org]=20 Sent: Friday, July 13, 2007 9:06 PM To: LTRU Working Group Subject: [Ltru] Macrolanguage and extlang =20 Addision and I have discussed the issue of extlang and Macrolanguages = and are proposing the following text replacing the use of extlang. [A new section called Macrolanguages: ] The Macrolanguage field contains a primary language subtag that = encompasses this subtag. That is, this language is a dialect or = sub-language of the Macrolanguage, and is called an encompassed subtag. = The Macrolanguage value is defined by ISO 639-3. The field can be useful = to applications or users when selecting language tags or as additional = metadata useful in matching. The Macrolanguage field can only occur in = records of type 'language'. Only values assigned by ISO 639-3 will be = considered for inclusion. Macrolanguage fields MAY be added via the = normal registration process whenever ISO 639-3 defines new values. = Macrolanguages are informational, and MAY be removed or changed if ISO = 639-3 changes the values. For example, the language subtags 'nb' (Norwegian Bokmal) and 'nn' = (Norwegian Nynorsk) has a Macrolanguage entry of 'no' (Norwegian). For = more information see [Choice].=20 [A new section in tag choice (section 4.1), referenced from the above]=20 Languages with a Macrolanguage field in the registry sometimes can be = usefully referenced using their Macrolanguage. However, the = Macrolanguage field doesn't define what the relationship is between the = language subtag whose record it appears in and its encompassed language = or languages. Nor does it define how the encompassed languages are = related to one-another. In some cases, the Macrolanguage has a standard = form as well as a variety of less-common dialects. For example, the = Macrolanguage 'ar' (Arabic) and the subtag 'arb' (Standard Arabic) = generally describe the same language, with other subtags describing = less-common local variations. In other cases there is no particular = standard form and the encompassed subtags describe specific variations = within the parent language.=20 Applications MAY use Macrolanguage information to improve matching or = language negotiation. For example, the information that 'sr' and 'hr' = share a Macrolanguage expresses a closer relation between those = languages than between, say, "sr" and "ma" (Macedonian). It is valid to = use either the encompassed language or its Macrolanguage to form = language tags. However, many matching applications will not be aware of = the relationship between the languages. Care in selecting which subtags = are used is crucial to interoperability. In general, use the most = specific tag. However, where the standard written form of an encompassed = language is captured by the Macrolanguage, the Macrolanguage should = still be used for written material. In particular, chinese language(s) and dialects call for special = consideration. Because the written form is very similar for most = languages having 'zh' as a Macrolanguage (and because historically = subtags for the various sub-languages and dialects were not available), = languages such as 'yue' (Cantonese) have usually used tags beginning = with the subtag 'zh'. This past practice of tagging means that = Macrolanguage information is encouraged when searching for content or = when providing fallbacks in language negotiation. For example, the = information that 'yue' has a macrolangauge of 'zh' could be used in the = Lookup algorithm to fallback from a request for "yue-Hans-CN" to = "zh-Hans-CN" without losing the script and region information (even = though the user did not specify "zh-Hans-CN" in their language priority = list).=20 However, the Macrolanguage is only one of many additional pieces of = information that can be used in matching languages. There are many = other circumstances where the "best fit" information is not contained in = the language registry. For example, the languages "ro" (Romanian) and = "mo" (Moldavian) are very closely related, and so for searching it is = often best to treat them as being the same. In other cases, the best = fallback for a requested language may be a completely unrelated = language, but one that a majority of speakers in the requested language = may understand. For example, in a given application the best fallback = for "be" (Breton), may be "fr" (French) -- rather than the more closely = related "cy" (Welsh) -- because Breton readers are far more likely to be = able to read French than Welsh. =20 For more information on matching, see [RFC 4647]. =20 [In the section talking about updates] The Macrolanguage field is added whenever a language has a corresponding = Macrolanguage in [ISO 639-3]. For example, 'sr' (Serbian) will have the = Macrolanguage value 'sh' (Serbo-Croatian). [Other changes] [Search for instances of "Suppress-Script" (just as a place to find = where field descriptions are) and make an addition of "Macrolanguage" if = appropriate, eg in the "LANGUAGE SUBTAG REGISTRATION FORM"] --=20 Mark=20 ------=_NextPart_000_0011_01C7C5F0.A9916710 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Mark, Thanks for this update. In reading this over (and = trying to see between the lines) with an eye to implications for many African languages and macrolanguages, the mention of Romanian/Moldavian seems particularly relevant, as an example of cases =C2=A0"where the = 'best fit' information is not contained in the language registry." This is an = area to which I hope that experts on African languages who have a familiarity = with tagging isues can be organized to propose amendments to the system (i.e., ISO = 639, which I realize is not the purview of this list, and the current = RFCs).

 

There are also cases where macrolanguages are defined, = but a still somewhat fluid situation wrt standardization makes defining their = use problematic (I've posted previously on some of the issues as I see them, = both on this list and on ietf-languages - such as cases where the language = tag may be less appropriate than the macrolanguage tag). =C2=A0Here too there = seems to be a need for input by experts on African languages in discussions of tagging = as well as in language planning.

 

In the meantime, I hope that the new wording can = accommodate all such situations, especially for languages with less resources and = emerging standards.

 

The fallback language issue (mentioned in the example re = Breton) raises another question: can there be more than one fallback language? = In the case of many of the crossborder languages in Africa (such as Hausa, = Swahili, Wolof, Fula, Tsonga, Oshiwambo, etc.) this would be = helpful.

 

Don

 

 

 

From:= Mark Davis [mailto:mark.davis@icu-project.org]
Sent: Friday, July 13, 2007 9:06 PM
To: LTRU Working Group
Subject: [Ltru] Macrolanguage and extlang

 

Addision and I have discussed the issue of extlang and Macrolanguages = and are proposing the following text replacing the use of = extlang.

[A new section called Macrolanguages: ]

The Macrolanguage field contains a primary language subtag that = encompasses this subtag. That is, this language is a dialect or sub-language of the Macrolanguage, and is called an encompassed subtag. The = Macrolanguage value is defined by ISO 639-3. The field can be useful to applications = or users when selecting language tags or as additional metadata useful in = matching. The Macrolanguage field can only occur in records of type 'language'. Only = values assigned by ISO 639-3 will be considered for inclusion. Macrolanguage = fields MAY be added via the normal registration process whenever ISO 639-3 = defines new values. Macrolanguages are informational, and MAY be removed or changed = if ISO 639-3 changes the values.

For example, the language subtags 'nb' (Norwegian = Bokmal) and 'nn' (Norwegian Nynorsk) has a Macrolanguage entry of 'no' = (Norwegian). For more information see [Choice].

[A new section in tag choice (section 4.1), referenced from the = above]

Languages with a Macrolanguage field in the registry sometimes can be usefully referenced using their Macrolanguage. However, the = Macrolanguage field doesn't define what the relationship is between the language subtag = whose record it appears in and its encompassed language or languages. Nor does = it define how the encompassed languages are related to one-another. In some = cases, the Macrolanguage has a standard form as well as a variety of = less-common dialects. For example, the Macrolanguage 'ar' (Arabic) and the subtag = 'arb' (Standard Arabic) generally describe the same language, with other = subtags describing less-common local variations. In other cases there is no = particular standard form and the encompassed subtags describe specific variations = within the parent language.

Applications MAY use Macrolanguage information to improve matching or language negotiation. For example, the information that 'sr' and 'hr' = share a Macrolanguage expresses a closer relation between those languages than = between, say, "sr" and "ma" (Macedonian). It is valid to use = either the encompassed language or its Macrolanguage to form language tags. = However, many matching applications will not be aware of the relationship between = the languages. Care in selecting which subtags are used is crucial to interoperability. In general, use the most specific tag. However, where = the standard written form of an encompassed language is captured by the Macrolanguage, the Macrolanguage should still be used for written = material.

In particular, chinese language(s) and dialects call for special consideration. Because the written form is very similar for most = languages having 'zh' as a Macrolanguage (and because historically subtags for the various sub-languages and dialects were not available), languages such = as 'yue' (Cantonese) have usually used tags beginning with the subtag 'zh'. This = past practice of tagging means that Macrolanguage information is encouraged = when searching for content or when providing fallbacks in language = negotiation. For example, the information that 'yue' has a macrolangauge of 'zh' could be = used in the Lookup algorithm to fallback from a request for = "yue-Hans-CN" to "zh-Hans-CN" without losing the script and region = information (even though the user did not specify "zh-Hans-CN" in their = language priority list).

However, the Macrolanguage is only one of many additional pieces of information  that can be used in matching languages. There are many = other circumstances where the "best fit" information is not = contained in the language registry. For example, the languages "ro" = (Romanian) and "mo" (Moldavian) are very closely related, and so for = searching it is often best to treat them as being the same. In other cases, the best = fallback for a requested language may be a completely unrelated language, but one = that a majority of speakers in the requested language may understand. For = example, in a given application the best fallback for "be" (Breton), may = be "fr" (French) -- rather than the more closely related = "cy" (Welsh) -- because Breton readers are far more likely to be able to read = French than Welsh.  

For more information on matching, see [RFC 4647]. =  

[In the section talking about updates]

The Macrolanguage field is added whenever a language has a = corresponding Macrolanguage in [ISO 639-3]. For example, 'sr' (Serbian) will have the Macrolanguage value 'sh' (Serbo-Croatian).

[Other changes]

[Search for instances of "Suppress-Script" (just as a place = to find where field descriptions are) and make an addition of "Macrolanguage" if appropriate, eg in the "LANGUAGE = SUBTAG REGISTRATION FORM"]



--
Mark

------=_NextPart_000_0011_01C7C5F0.A9916710-- --===============1827110673== 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 --===============1827110673==-- From ltru-bounces@ietf.org Sat Jul 14 12:32:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9kXk-0003ck-7N; Sat, 14 Jul 2007 12:32:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I9kXj-0003cf-SB for ltru-confirm+ok@megatron.ietf.org; Sat, 14 Jul 2007 12:32:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9kXj-0003cU-Ew for ltru@ietf.org; Sat, 14 Jul 2007 12:32:27 -0400 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9kXf-0005dw-LY for ltru@ietf.org; Sat, 14 Jul 2007 12:32:27 -0400 Received: by nz-out-0506.google.com with SMTP id n1so622982nzf for ; Sat, 14 Jul 2007 09:32:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=GTsZufDjrRcbWJXsqZiiOXPihTipUxi/jHkqzOBygABsxYaQ5QFLXBbiYXbr/Nl/vBaA0STdok8RcydV1FBdoygwy7cIbJ20mjUyB2yli7gl/Nu6vCk2CUUO/Uo3ezXrpt4y7Ht12Qc4eGjMmFetYsK80OYN/7Edo5qZJSXhIkU= 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=aW2EFuYM3cHd4M+F3SG7c7WMAPfO4hLL8dUN9uAmTejuFjRuC6pqx6V9sxRdYc5Ceajdf4ZvPLri4YVZs78DU4xVgKhMi/4i9BmMelEBEDek4tAjSYp0Q8rjdX56gM1yObl5Z3QKmuAUbte+Kp2Ji35OslLr7t76eBFywoYFxkM= Received: by 10.114.106.1 with SMTP id e1mr2663577wac.1184430742381; Sat, 14 Jul 2007 09:32:22 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Sat, 14 Jul 2007 09:32:22 -0700 (PDT) Message-ID: <30b660a20707140932qa998ab3y23d07c062d08aab1@mail.gmail.com> Date: Sat, 14 Jul 2007 09:32:22 -0700 From: "Mark Davis" To: "Don Osborn" Subject: Re: [Ltru] Macrolanguage and extlang In-Reply-To: <001001c7c612$30a30710$91e91530$@net> MIME-Version: 1.0 References: <30b660a20707131806o19919cc7v97cc82f3eada43ff@mail.gmail.com> <001001c7c612$30a30710$91e91530$@net> X-Google-Sender-Auth: 7172d7f503618f10 X-Spam-Score: 0.5 (/) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 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="===============1285593298==" Errors-To: ltru-bounces@ietf.org --===============1285593298== Content-Type: multipart/alternative; boundary="----=_Part_48557_15346368.1184430742342" ------=_Part_48557_15346368.1184430742342 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks. I think one of the things that we realized when looking at how this would work in practice is that we are better off if we treat macrolanguage as a piece of very useful information for matching, but one that can be enhanced (that is, changed) over time as more information becomes available. Hard-coding it into extlang doesn't serve that purpose, and causes other problems, notably that the other fields are lost in fallback: if we had zh-yue-Hant, then by the time we get to zh in fallback, we've lost the Hant. So that is the origin of the text we are proposing. There are a number of edge cases such as deprecated codes, closely related languages, or practical fallbacks (eg if someone speaks X they are likely to speak Y, even if X and Y are not linguistically related) that are simply unsuited to hard-coding in the tag. If I hit a code like "iw-PL", I want to match that with "he-PL", not depend on some kind of fallback between "iw" and "he"; otherwise it loses information (the PL). We do provide that kind of information in the deprecated field, and with the macrolanguage field we would provide more (for example, it would make clear the relation between no, nb, and nn and how that could be used in matching). Other useful information is the scripts used with a language in practice; suppress script supplies just a little information, but doesn't tell me that Uzbek is customarily written with Arabic, Latin, or Cyrillic, but not with (say) Tagalog. The more information there is available, whether it be in the language subtag registry or somewhere else, the better a job people can do in dealing with some of the edge cases that turn up in matching. Mark On 7/14/07, Don Osborn wrote: > > Mark, Thanks for this update. In reading this over (and trying to see > between the lines) with an eye to implications for many African languages > and macrolanguages, the mention of Romanian/Moldavian seems particularly > relevant, as an example of cases "where the 'best fit' information is not > contained in the language registry." This is an area to which I hope that > experts on African languages who have a familiarity with tagging isues can > be organized to propose amendments to the system (i.e., ISO 639, which I > realize is not the purview of this list, and the current RFCs). > > > > There are also cases where macrolanguages are defined, but a still > somewhat fluid situation wrt standardization makes defining their use > problematic (I've posted previously on some of the issues as I see them, > both on this list and on ietf-languages - such as cases where the language > tag may be less appropriate than the macrolanguage tag). Here too there > seems to be a need for input by experts on African languages in discussions > of tagging as well as in language planning. > > > > In the meantime, I hope that the new wording can accommodate all such > situations, especially for languages with less resources and emerging > standards. > > > > The fallback language issue (mentioned in the example re Breton) raises > another question: can there be more than one fallback language? In the case > of many of the crossborder languages in Africa (such as Hausa, Swahili, > Wolof, Fula, Tsonga, Oshiwambo, etc.) this would be helpful. > > > > Don > > > > > > > > *From:* Mark Davis [mailto:mark.davis@icu-project.org] > *Sent:* Friday, July 13, 2007 9:06 PM > *To:* LTRU Working Group > *Subject:* [Ltru] Macrolanguage and extlang > > > > Addision and I have discussed the issue of extlang and Macrolanguages and > are proposing the following text replacing the use of extlang. > > *[A new section called Macrolanguages: ]* > > The Macrolanguage field contains a primary language subtag that * > encompasses* this subtag. That is, this language is a dialect or > sub-language of the Macrolanguage, and is called an *encompassed* subtag. > The Macrolanguage value is defined by ISO 639-3. The field can be useful to > applications or users when selecting language tags or as additional metadata > useful in matching. The Macrolanguage field can only occur in records of > type 'language'. Only values assigned by ISO 639-3 will be considered for > inclusion. Macrolanguage fields MAY be added via the normal registration > process whenever ISO 639-3 defines new values. Macrolanguages are > informational, and MAY be removed or changed if ISO 639-3 changes the > values. > > For example, the language subtags 'nb' (Norwegian Bokmal) and 'nn' > (Norwegian Nynorsk) has a Macrolanguage entry of 'no' (Norwegian). For more > information see [Choice]. > > *[A new section in tag choice (section 4.1), referenced from the above] * > > Languages with a Macrolanguage field in the registry sometimes can be > usefully referenced using their Macrolanguage. However, the Macrolanguage > field doesn't define what the relationship is between the language subtag > whose record it appears in and its encompassed language or languages. Nor > does it define how the encompassed languages are related to one-another. In > some cases, the Macrolanguage has a standard form as well as a variety of > less-common dialects. For example, the Macrolanguage 'ar' (Arabic) and the > subtag 'arb' (Standard Arabic) generally describe the same language, with > other subtags describing less-common local variations. In other cases there > is no particular standard form and the encompassed subtags describe specific > variations within the parent language. > > Applications MAY use Macrolanguage information to improve matching or > language negotiation. For example, the information that 'sr' and 'hr' share > a Macrolanguage expresses a closer relation between those languages than > between, say, "sr" and "ma" (Macedonian). It is valid to use either the > encompassed language or its Macrolanguage to form language tags. However, > many matching applications will not be aware of the relationship between the > languages. Care in selecting which subtags are used is crucial to > interoperability. In general, use the most specific tag. However, where the > standard written form of an encompassed language is captured by the > Macrolanguage, the Macrolanguage should still be used for written material. > > In particular, chinese language(s) and dialects call for special > consideration. Because the written form is very similar for most languages > having 'zh' as a Macrolanguage (and because historically subtags for the > various sub-languages and dialects were not available), languages such as > 'yue' (Cantonese) have usually used tags beginning with the subtag 'zh'. > This past practice of tagging means that Macrolanguage information is > encouraged when searching for content or when providing fallbacks in > language negotiation. For example, the information that 'yue' has a > macrolangauge of 'zh' could be used in the Lookup algorithm to fallback from > a request for "yue-Hans-CN" to "zh-Hans-CN" *without losing the script and > region information* (even though the user did not specify "zh-Hans-CN" in > their language priority list). > > However, the Macrolanguage is only one of many additional pieces of > information that can be used in matching languages. There are many other > circumstances where the "best fit" information is not contained in the > language registry. For example, the languages "ro" (Romanian) and "mo" > (Moldavian) are very closely related, and so for searching it is often best > to treat them as being the same. In other cases, the best fallback for a > requested language may be a completely unrelated language, but one that a > majority of speakers in the requested language may understand. For example, > in a given application the best fallback for "be" (Breton), may be "fr" > (French) -- rather than the more closely related "cy" (Welsh) -- because > Breton readers are far more likely to be able to read French than Welsh. > > For more information on matching, see [RFC 4647]. > > *[In the section talking about updates]* > > The Macrolanguage field is added whenever a language has a corresponding > Macrolanguage in [ISO 639-3]. For example, 'sr' (Serbian) will have the > Macrolanguage value 'sh' (Serbo-Croatian). > > *[Other changes]* > > [Search for instances of "Suppress-Script" (just as a place to find where > field descriptions are) and make an addition of "Macrolanguage" if > appropriate, eg in the "LANGUAGE SUBTAG REGISTRATION FORM"] > > > > -- > Mark > -- Mark ------=_Part_48557_15346368.1184430742342 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhhbmtzLjxicj48YnI+SSB0aGluayBvbmUgb2YgdGhlIHRoaW5ncyB0aGF0IHdlIHJlYWxpemVk IHdoZW4gbG9va2luZyBhdCBob3cgdGhpcyB3b3VsZCB3b3JrIGluIHByYWN0aWNlIGlzIHRoYXQg d2UgYXJlIGJldHRlciBvZmYgaWYgd2UgdHJlYXQgbWFjcm9sYW5ndWFnZSBhcyBhIHBpZWNlIG9m IHZlcnkgdXNlZnVsIGluZm9ybWF0aW9uIGZvciBtYXRjaGluZywgYnV0IG9uZSB0aGF0IGNhbiBi ZSBlbmhhbmNlZCAodGhhdCBpcywgY2hhbmdlZCkgb3ZlciB0aW1lIGFzIG1vcmUgaW5mb3JtYXRp b24gYmVjb21lcyBhdmFpbGFibGUuIEhhcmQtY29kaW5nIGl0IGludG8gZXh0bGFuZyBkb2VzbiYj Mzk7dCBzZXJ2ZSB0aGF0IHB1cnBvc2UsIGFuZCBjYXVzZXMgb3RoZXIgcHJvYmxlbXMsIG5vdGFi bHkgdGhhdCB0aGUgb3RoZXIgZmllbGRzIGFyZSBsb3N0IGluIGZhbGxiYWNrOiBpZiB3ZSBoYWQg emgteXVlLUhhbnQsIHRoZW4gYnkgdGhlIHRpbWUgd2UgZ2V0IHRvIHpoIGluIGZhbGxiYWNrLCB3 ZSYjMzk7dmUgbG9zdCB0aGUgSGFudC4KPGJyPjxicj5TbyB0aGF0IGlzIHRoZSBvcmlnaW4gb2Yg dGhlIHRleHQgd2UgYXJlIHByb3Bvc2luZy48YnI+PGJyPlRoZXJlIGFyZSBhIG51bWJlciBvZiBl ZGdlIGNhc2VzIHN1Y2ggYXMgZGVwcmVjYXRlZCBjb2RlcywgY2xvc2VseSByZWxhdGVkIGxhbmd1 YWdlcywgb3IgcHJhY3RpY2FsIGZhbGxiYWNrcyAoZWcgaWYgc29tZW9uZSBzcGVha3MgWCB0aGV5 IGFyZSBsaWtlbHkgdG8gc3BlYWsgWSwgZXZlbiBpZiBYIGFuZCBZIGFyZSBub3QgbGluZ3Vpc3Rp Y2FsbHkgcmVsYXRlZCkgdGhhdCBhcmUgc2ltcGx5IHVuc3VpdGVkIHRvIGhhcmQtY29kaW5nIGlu IHRoZSB0YWcuIElmIEkgaGl0IGEgY29kZSBsaWtlICZxdW90O2l3LVBMJnF1b3Q7LCBJIHdhbnQg dG8gbWF0Y2ggdGhhdCB3aXRoICZxdW90O2hlLVBMJnF1b3Q7LCBub3QgZGVwZW5kIG9uIHNvbWUg a2luZCBvZiBmYWxsYmFjayBiZXR3ZWVuICZxdW90O2l3JnF1b3Q7IGFuZCAmcXVvdDtoZSZxdW90 Ozsgb3RoZXJ3aXNlIGl0IGxvc2VzIGluZm9ybWF0aW9uICh0aGUgUEwpLiBXZSBkbyBwcm92aWRl IHRoYXQga2luZCBvZiBpbmZvcm1hdGlvbiBpbiB0aGUgZGVwcmVjYXRlZCBmaWVsZCwgYW5kIHdp dGggdGhlIG1hY3JvbGFuZ3VhZ2UgZmllbGQgd2Ugd291bGQgcHJvdmlkZSBtb3JlIChmb3IgZXhh bXBsZSwgaXQgd291bGQgbWFrZSBjbGVhciB0aGUgcmVsYXRpb24gYmV0d2VlbiBubywgbmIsIGFu ZCBubiBhbmQgaG93IHRoYXQgY291bGQgYmUgdXNlZCBpbiBtYXRjaGluZykuIE90aGVyIHVzZWZ1 bCBpbmZvcm1hdGlvbiBpcyB0aGUgc2NyaXB0cyB1c2VkIHdpdGggYSBsYW5ndWFnZSBpbiBwcmFj dGljZTsgc3VwcHJlc3Mgc2NyaXB0IHN1cHBsaWVzIGp1c3QgYSBsaXR0bGUgaW5mb3JtYXRpb24s IGJ1dCBkb2VzbiYjMzk7dCB0ZWxsIG1lIHRoYXQgVXpiZWsgaXMgY3VzdG9tYXJpbHkgd3JpdHRl biB3aXRoIEFyYWJpYywgTGF0aW4sIG9yIEN5cmlsbGljLCBidXQgbm90IHdpdGggKHNheSkgVGFn YWxvZy4KPGJyPjxicj5UaGUgbW9yZSBpbmZvcm1hdGlvbiB0aGVyZSBpcyBhdmFpbGFibGUsIHdo ZXRoZXIgaXQgYmUgaW4gdGhlIGxhbmd1YWdlIHN1YnRhZyByZWdpc3RyeSBvciBzb21ld2hlcmUg ZWxzZSwgdGhlIGJldHRlciBhIGpvYiBwZW9wbGUgY2FuIGRvIGluIGRlYWxpbmcgd2l0aCBzb21l IG9mIHRoZSBlZGdlIGNhc2VzIHRoYXQgdHVybiB1cCBpbiBtYXRjaGluZy48YnI+PGJyPk1hcmsK PGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNy8xNC8wNywgPGIgY2xh c3M9ImdtYWlsX3NlbmRlcm5hbWUiPkRvbiBPc2Jvcm48L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86 ZHpvQGJpc2hhcmF0Lm5ldCI+ZHpvQGJpc2hhcmF0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNv bGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGlu Zy1sZWZ0OiAxZXg7Ij4KCgoKCgoKCgoKPGRpdiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBs YW5nPSJFTi1VUyI+Cgo8ZGl2PgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5NYXJrLCBUaGFua3MgZm9yIHRoaXMgdXBkYXRlLiBJbiBy ZWFkaW5nIHRoaXMgb3ZlciAoYW5kIHRyeWluZwp0byBzZWUgYmV0d2VlbiB0aGUgbGluZXMpIHdp dGggYW4gZXllIHRvIGltcGxpY2F0aW9ucyBmb3IgbWFueSBBZnJpY2FuCmxhbmd1YWdlcyBhbmQg bWFjcm9sYW5ndWFnZXMsIHRoZSBtZW50aW9uIG9mIFJvbWFuaWFuL01vbGRhdmlhbiBzZWVtcwpw YXJ0aWN1bGFybHkgcmVsZXZhbnQsIGFzIGFuIGV4YW1wbGUgb2YgY2FzZXMgJm5ic3A7JnF1b3Q7 d2hlcmUgdGhlICYjMzk7YmVzdCBmaXQmIzM5OwppbmZvcm1hdGlvbiBpcyBub3QgY29udGFpbmVk IGluIHRoZSBsYW5ndWFnZSByZWdpc3RyeS4mcXVvdDsgVGhpcyBpcyBhbiBhcmVhIHRvCndoaWNo IEkgaG9wZSB0aGF0IGV4cGVydHMgb24gQWZyaWNhbiBsYW5ndWFnZXMgd2hvIGhhdmUgYSBmYW1p bGlhcml0eSB3aXRoIHRhZ2dpbmcKaXN1ZXMgY2FuIGJlIG9yZ2FuaXplZCB0byBwcm9wb3NlIGFt ZW5kbWVudHMgdG8gdGhlIHN5c3RlbSAoaS5lLiwgSVNPIDYzOSwKd2hpY2ggSSByZWFsaXplIGlz IG5vdCB0aGUgcHVydmlldyBvZiB0aGlzIGxpc3QsIGFuZCB0aGUgY3VycmVudCBSRkNzKS48L3Nw YW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5UaGVyZSBhcmUgYWxzbyBjYXNlcyB3aGVy ZSBtYWNyb2xhbmd1YWdlcyBhcmUgZGVmaW5lZCwgYnV0IGEKc3RpbGwgc29tZXdoYXQgZmx1aWQg c2l0dWF0aW9uIHdydCBzdGFuZGFyZGl6YXRpb24gbWFrZXMgZGVmaW5pbmcgdGhlaXIgdXNlCnBy b2JsZW1hdGljIChJJiMzOTt2ZSBwb3N0ZWQgcHJldmlvdXNseSBvbiBzb21lIG9mIHRoZSBpc3N1 ZXMgYXMgSSBzZWUgdGhlbSwgYm90aApvbiB0aGlzIGxpc3QgYW5kIG9uIGlldGYtbGFuZ3VhZ2Vz IC0gc3VjaCBhcyBjYXNlcyB3aGVyZSB0aGUgbGFuZ3VhZ2UgdGFnIG1heQpiZSBsZXNzIGFwcHJv cHJpYXRlIHRoYW4gdGhlIG1hY3JvbGFuZ3VhZ2UgdGFnKS4gJm5ic3A7SGVyZSB0b28gdGhlcmUg c2VlbXMgdG8gYmUgYQpuZWVkIGZvciBpbnB1dCBieSBleHBlcnRzIG9uIEFmcmljYW4gbGFuZ3Vh Z2VzIGluIGRpc2N1c3Npb25zIG9mIHRhZ2dpbmcgYXMKd2VsbCBhcyBpbiBsYW5ndWFnZSBwbGFu bmluZy48L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5JbiB0aGUgbWVhbnRpbWUs IEkgaG9wZSB0aGF0IHRoZSBuZXcgd29yZGluZyBjYW4gYWNjb21tb2RhdGUgYWxsCnN1Y2ggc2l0 dWF0aW9ucywgZXNwZWNpYWxseSBmb3IgbGFuZ3VhZ2VzIHdpdGggbGVzcyByZXNvdXJjZXMgYW5k IGVtZXJnaW5nCnN0YW5kYXJkcy48L3NwYW4+PC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9wPgoKPHA+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5U aGUgZmFsbGJhY2sgbGFuZ3VhZ2UgaXNzdWUgKG1lbnRpb25lZCBpbiB0aGUgZXhhbXBsZSByZSBC cmV0b24pCnJhaXNlcyBhbm90aGVyIHF1ZXN0aW9uOiBjYW4gdGhlcmUgYmUgbW9yZSB0aGFuIG9u ZSBmYWxsYmFjayBsYW5ndWFnZT8gSW4gdGhlCmNhc2Ugb2YgbWFueSBvZiB0aGUgY3Jvc3Nib3Jk ZXIgbGFuZ3VhZ2VzIGluIEFmcmljYSAoc3VjaCBhcyBIYXVzYSwgU3dhaGlsaSwKV29sb2YsIEZ1 bGEsIFRzb25nYSwgT3NoaXdhbWJvLCBldGMuKSB0aGlzIHdvdWxkIGJlIGhlbHBmdWwuPC9zcGFu PjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+RG9uPC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9z cGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvcD4KCjxkaXYg c3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1jb2xvcjog LW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29s b3IgYmx1ZTsgYm9yZGVyLXdpZHRoOiBtZWRpdW0gbWVkaXVtIG1lZGl1bSAxLjVwdDsgcGFkZGlu ZzogMGluIDBpbiAwaW4gNHB0OyI+Cgo8ZGl2PgoKPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBz b2xpZCBub25lIG5vbmU7IGJvcmRlci1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpIC1tb3otdXNl LXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvcjsgYm9yZGVyLXdpZHRoOiAxcHQgbWVkaXVt IG1lZGl1bTsgcGFkZGluZzogM3B0IDBpbiAwaW47Ij4KCjxwPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwcHQ7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBw dDsiPiBNYXJrIERhdmlzClttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hcmsuZGF2aXNAaWN1LXBy b2plY3Qub3JnIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0 TGluayh3aW5kb3csZXZlbnQsdGhpcykiPm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnPC9hPl0g PGJyPgo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDEzLCAyMDA3IDk6MDYgUE08YnI+CjxiPlRv OjwvYj4gTFRSVSBXb3JraW5nIEdyb3VwPGJyPgo8Yj5TdWJqZWN0OjwvYj4gW0x0cnVdIE1hY3Jv bGFuZ3VhZ2UgYW5kIGV4dGxhbmc8L3NwYW4+PC9wPgoKPC9kaXY+Cgo8L2Rpdj48ZGl2PjxzcGFu IGNsYXNzPSJlIiBpZD0icV8xMTNjNGIxYzIwNGEzMmVlXzEiPgoKPHA+Jm5ic3A7PC9wPgoKPHA+ QWRkaXNpb24gYW5kIEkgaGF2ZSBkaXNjdXNzZWQgdGhlIGlzc3VlIG9mIGV4dGxhbmcgYW5kIE1h Y3JvbGFuZ3VhZ2VzIGFuZAphcmUgcHJvcG9zaW5nIHRoZSBmb2xsb3dpbmcgdGV4dCByZXBsYWNp bmcgdGhlIHVzZSBvZiBleHRsYW5nLjwvcD4KCjxwPjxiPltBIG5ldyBzZWN0aW9uIGNhbGxlZCBN YWNyb2xhbmd1YWdlczogXTwvYj48L3A+Cgo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDog NXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7Ij4KCjxwPlRoZSBNYWNyb2xhbmd1YWdlIGZpZWxkIGNv bnRhaW5zIGEgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgdGhhdCA8aT5lbmNvbXBhc3NlczwvaT4K dGhpcyBzdWJ0YWcuIFRoYXQgaXMsIHRoaXMgbGFuZ3VhZ2UgaXMgYSBkaWFsZWN0IG9yIHN1Yi1s YW5ndWFnZSBvZiB0aGUKTWFjcm9sYW5ndWFnZSwgYW5kIGlzIGNhbGxlZCBhbiA8aT5lbmNvbXBh c3NlZDwvaT4gc3VidGFnLiBUaGUgTWFjcm9sYW5ndWFnZQp2YWx1ZSBpcyBkZWZpbmVkIGJ5IElT TyA2MzktMy4gVGhlIGZpZWxkIGNhbiBiZSB1c2VmdWwgdG8gYXBwbGljYXRpb25zIG9yIHVzZXJz CndoZW4gc2VsZWN0aW5nIGxhbmd1YWdlIHRhZ3Mgb3IgYXMgYWRkaXRpb25hbCBtZXRhZGF0YSB1 c2VmdWwgaW4gbWF0Y2hpbmcuIFRoZQpNYWNyb2xhbmd1YWdlIGZpZWxkIGNhbiBvbmx5IG9jY3Vy IGluIHJlY29yZHMgb2YgdHlwZSAmIzM5O2xhbmd1YWdlJiMzOTsuIE9ubHkgdmFsdWVzCmFzc2ln bmVkIGJ5IElTTyA2MzktMyB3aWxsIGJlIGNvbnNpZGVyZWQgZm9yIGluY2x1c2lvbi4gTWFjcm9s YW5ndWFnZSBmaWVsZHMKTUFZIGJlIGFkZGVkIHZpYSB0aGUgbm9ybWFsIHJlZ2lzdHJhdGlvbiBw cm9jZXNzIHdoZW5ldmVyIElTTyA2MzktMyBkZWZpbmVzIG5ldwp2YWx1ZXMuIE1hY3JvbGFuZ3Vh Z2VzIGFyZSBpbmZvcm1hdGlvbmFsLCBhbmQgTUFZIGJlIHJlbW92ZWQgb3IgY2hhbmdlZCBpZiBJ U08KNjM5LTMgY2hhbmdlcyB0aGUgdmFsdWVzLjwvcD4KCjxwPkZvciBleGFtcGxlLCB0aGUgbGFu Z3VhZ2Ugc3VidGFncyAmIzM5O25iJiMzOTsgKE5vcndlZ2lhbiBCb2ttYWwpCmFuZCAmIzM5O25u JiMzOTsgKE5vcndlZ2lhbiBOeW5vcnNrKSBoYXMgYSBNYWNyb2xhbmd1YWdlIGVudHJ5IG9mICYj Mzk7bm8mIzM5OyAoTm9yd2VnaWFuKS4gRm9yCm1vcmUgaW5mb3JtYXRpb24gc2VlIFtDaG9pY2Vd LiA8L3A+Cgo8L2Jsb2NrcXVvdGU+Cgo8cD48Yj5bQSBuZXcgc2VjdGlvbiBpbiB0YWcgY2hvaWNl IChzZWN0aW9uIDQuMSksIHJlZmVyZW5jZWQgZnJvbSB0aGUgYWJvdmVdIDwvYj48L3A+Cgo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7Ij4KCjxw Pkxhbmd1YWdlcyB3aXRoIGEgTWFjcm9sYW5ndWFnZSBmaWVsZCBpbiB0aGUgcmVnaXN0cnkgc29t ZXRpbWVzIGNhbiBiZQp1c2VmdWxseSByZWZlcmVuY2VkIHVzaW5nIHRoZWlyIE1hY3JvbGFuZ3Vh Z2UuIEhvd2V2ZXIsIHRoZSBNYWNyb2xhbmd1YWdlIGZpZWxkCmRvZXNuJiMzOTt0IGRlZmluZSB3 aGF0IHRoZSByZWxhdGlvbnNoaXAgaXMgYmV0d2VlbiB0aGUgbGFuZ3VhZ2Ugc3VidGFnIHdob3Nl CnJlY29yZCBpdCBhcHBlYXJzIGluIGFuZCBpdHMgZW5jb21wYXNzZWQgbGFuZ3VhZ2Ugb3IgbGFu Z3VhZ2VzLiBOb3IgZG9lcyBpdApkZWZpbmUgaG93IHRoZSBlbmNvbXBhc3NlZCBsYW5ndWFnZXMg YXJlIHJlbGF0ZWQgdG8gb25lLWFub3RoZXIuIEluIHNvbWUgY2FzZXMsCnRoZSBNYWNyb2xhbmd1 YWdlIGhhcyBhIHN0YW5kYXJkIGZvcm0gYXMgd2VsbCBhcyBhIHZhcmlldHkgb2YgbGVzcy1jb21t b24KZGlhbGVjdHMuIEZvciBleGFtcGxlLCB0aGUgTWFjcm9sYW5ndWFnZSAmIzM5O2FyJiMzOTsg KEFyYWJpYykgYW5kIHRoZSBzdWJ0YWcgJiMzOTthcmImIzM5OwooU3RhbmRhcmQgQXJhYmljKSBn ZW5lcmFsbHkgZGVzY3JpYmUgdGhlIHNhbWUgbGFuZ3VhZ2UsIHdpdGggb3RoZXIgc3VidGFncwpk ZXNjcmliaW5nIGxlc3MtY29tbW9uIGxvY2FsIHZhcmlhdGlvbnMuIEluIG90aGVyIGNhc2VzIHRo ZXJlIGlzIG5vIHBhcnRpY3VsYXIKc3RhbmRhcmQgZm9ybSBhbmQgdGhlIGVuY29tcGFzc2VkIHN1 YnRhZ3MgZGVzY3JpYmUgc3BlY2lmaWMgdmFyaWF0aW9ucyB3aXRoaW4KdGhlIHBhcmVudCBsYW5n dWFnZS4gPC9wPgoKPHA+QXBwbGljYXRpb25zIE1BWSB1c2UgTWFjcm9sYW5ndWFnZSBpbmZvcm1h dGlvbiB0byBpbXByb3ZlIG1hdGNoaW5nIG9yCmxhbmd1YWdlIG5lZ290aWF0aW9uLiBGb3IgZXhh bXBsZSwgdGhlIGluZm9ybWF0aW9uIHRoYXQgJiMzOTtzciYjMzk7IGFuZCAmIzM5O2hyJiMzOTsg c2hhcmUgYQpNYWNyb2xhbmd1YWdlIGV4cHJlc3NlcyBhIGNsb3NlciByZWxhdGlvbiBiZXR3ZWVu IHRob3NlIGxhbmd1YWdlcyB0aGFuIGJldHdlZW4sCnNheSwgJnF1b3Q7c3ImcXVvdDsgYW5kICZx dW90O21hJnF1b3Q7IChNYWNlZG9uaWFuKS4gSXQgaXMgdmFsaWQgdG8gdXNlIGVpdGhlcgp0aGUg ZW5jb21wYXNzZWQgbGFuZ3VhZ2Ugb3IgaXRzIE1hY3JvbGFuZ3VhZ2UgdG8gZm9ybSBsYW5ndWFn ZSB0YWdzLiBIb3dldmVyLAptYW55IG1hdGNoaW5nIGFwcGxpY2F0aW9ucyB3aWxsIG5vdCBiZSBh d2FyZSBvZiB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlCmxhbmd1YWdlcy4gQ2FyZSBpbiBz ZWxlY3Rpbmcgd2hpY2ggc3VidGFncyBhcmUgdXNlZCBpcyBjcnVjaWFsIHRvCmludGVyb3BlcmFi aWxpdHkuIEluIGdlbmVyYWwsIHVzZSB0aGUgbW9zdCBzcGVjaWZpYyB0YWcuIEhvd2V2ZXIsIHdo ZXJlIHRoZQpzdGFuZGFyZCB3cml0dGVuIGZvcm0gb2YgYW4gZW5jb21wYXNzZWQgbGFuZ3VhZ2Ug aXMgY2FwdHVyZWQgYnkgdGhlCk1hY3JvbGFuZ3VhZ2UsIHRoZSBNYWNyb2xhbmd1YWdlIHNob3Vs ZCBzdGlsbCBiZSB1c2VkIGZvciB3cml0dGVuIG1hdGVyaWFsLjwvcD4KCjxwPkluIHBhcnRpY3Vs YXIsIGNoaW5lc2UgbGFuZ3VhZ2UocykgYW5kIGRpYWxlY3RzIGNhbGwgZm9yIHNwZWNpYWwKY29u c2lkZXJhdGlvbi4gQmVjYXVzZSB0aGUgd3JpdHRlbiBmb3JtIGlzIHZlcnkgc2ltaWxhciBmb3Ig bW9zdCBsYW5ndWFnZXMKaGF2aW5nICYjMzk7emgmIzM5OyBhcyBhIE1hY3JvbGFuZ3VhZ2UgKGFu ZCBiZWNhdXNlIGhpc3RvcmljYWxseSBzdWJ0YWdzIGZvciB0aGUKdmFyaW91cyBzdWItbGFuZ3Vh Z2VzIGFuZCBkaWFsZWN0cyB3ZXJlIG5vdCBhdmFpbGFibGUpLCBsYW5ndWFnZXMgc3VjaCBhcyAm IzM5O3l1ZSYjMzk7CihDYW50b25lc2UpIGhhdmUgdXN1YWxseSB1c2VkIHRhZ3MgYmVnaW5uaW5n IHdpdGggdGhlIHN1YnRhZyAmIzM5O3poJiMzOTsuIFRoaXMgcGFzdApwcmFjdGljZSBvZiB0YWdn aW5nIG1lYW5zIHRoYXQgTWFjcm9sYW5ndWFnZSBpbmZvcm1hdGlvbiBpcyBlbmNvdXJhZ2VkIHdo ZW4Kc2VhcmNoaW5nIGZvciBjb250ZW50IG9yIHdoZW4gcHJvdmlkaW5nIGZhbGxiYWNrcyBpbiBs YW5ndWFnZSBuZWdvdGlhdGlvbi4gRm9yCmV4YW1wbGUsIHRoZSBpbmZvcm1hdGlvbiB0aGF0ICYj Mzk7eXVlJiMzOTsgaGFzIGEgbWFjcm9sYW5nYXVnZSBvZiAmIzM5O3poJiMzOTsgY291bGQgYmUg dXNlZAppbiB0aGUgTG9va3VwIGFsZ29yaXRobSB0byBmYWxsYmFjayBmcm9tIGEgcmVxdWVzdCBm b3IgJnF1b3Q7eXVlLUhhbnMtQ04mcXVvdDsKdG8gJnF1b3Q7emgtSGFucy1DTiZxdW90OyA8aT53 aXRob3V0IGxvc2luZyB0aGUgc2NyaXB0IGFuZCByZWdpb24gaW5mb3JtYXRpb248L2k+CihldmVu IHRob3VnaCB0aGUgdXNlciBkaWQgbm90IHNwZWNpZnkgJnF1b3Q7emgtSGFucy1DTiZxdW90OyBp biB0aGVpciBsYW5ndWFnZQpwcmlvcml0eSBsaXN0KS4gPC9wPgoKPHA+SG93ZXZlciwgdGhlIE1h Y3JvbGFuZ3VhZ2UgaXMgb25seSBvbmUgb2YgbWFueSBhZGRpdGlvbmFsIHBpZWNlcyBvZgppbmZv cm1hdGlvbiAmbmJzcDt0aGF0IGNhbiBiZSB1c2VkIGluIG1hdGNoaW5nIGxhbmd1YWdlcy4gVGhl cmUgYXJlIG1hbnkgb3RoZXIKY2lyY3Vtc3RhbmNlcyB3aGVyZSB0aGUgJnF1b3Q7YmVzdCBmaXQm cXVvdDsgaW5mb3JtYXRpb24gaXMgbm90IGNvbnRhaW5lZCBpbgp0aGUgbGFuZ3VhZ2UgcmVnaXN0 cnkuIEZvciBleGFtcGxlLCB0aGUgbGFuZ3VhZ2VzICZxdW90O3JvJnF1b3Q7IChSb21hbmlhbikg YW5kCiZxdW90O21vJnF1b3Q7IChNb2xkYXZpYW4pIGFyZSB2ZXJ5IGNsb3NlbHkgcmVsYXRlZCwg YW5kIHNvIGZvciBzZWFyY2hpbmcgaXQgaXMKb2Z0ZW4gYmVzdCB0byB0cmVhdCB0aGVtIGFzIGJl aW5nIHRoZSBzYW1lLiBJbiBvdGhlciBjYXNlcywgdGhlIGJlc3QgZmFsbGJhY2sKZm9yIGEgcmVx dWVzdGVkIGxhbmd1YWdlIG1heSBiZSBhIGNvbXBsZXRlbHkgdW5yZWxhdGVkIGxhbmd1YWdlLCBi dXQgb25lIHRoYXQgYQptYWpvcml0eSBvZiBzcGVha2VycyBpbiB0aGUgcmVxdWVzdGVkIGxhbmd1 YWdlIG1heSB1bmRlcnN0YW5kLiBGb3IgZXhhbXBsZSwgaW4KYSBnaXZlbiBhcHBsaWNhdGlvbiB0 aGUgYmVzdCBmYWxsYmFjayBmb3IgJnF1b3Q7YmUmcXVvdDsgKEJyZXRvbiksIG1heSBiZQomcXVv dDtmciZxdW90OyAoRnJlbmNoKSAtLSByYXRoZXIgdGhhbiB0aGUgbW9yZSBjbG9zZWx5IHJlbGF0 ZWQgJnF1b3Q7Y3kmcXVvdDsKKFdlbHNoKSAtLSBiZWNhdXNlIEJyZXRvbiByZWFkZXJzIGFyZSBm YXIgbW9yZSBsaWtlbHkgdG8gYmUgYWJsZSB0byByZWFkIEZyZW5jaAp0aGFuIFdlbHNoLiAmbmJz cDs8L3A+Cgo8cD5Gb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBtYXRjaGluZywgc2VlIFtSRkMgNDY0 N10uICZuYnNwOzwvcD4KCjwvYmxvY2txdW90ZT4KCjxwPjxiPltJbiB0aGUgc2VjdGlvbiB0YWxr aW5nIGFib3V0IHVwZGF0ZXNdPC9iPjwvcD4KCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiPgoKPHA+VGhlIE1hY3JvbGFuZ3VhZ2UgZmllbGQg aXMgYWRkZWQgd2hlbmV2ZXIgYSBsYW5ndWFnZSBoYXMgYSBjb3JyZXNwb25kaW5nCk1hY3JvbGFu Z3VhZ2UgaW4gW0lTTyA2MzktM10uIEZvciBleGFtcGxlLCAmIzM5O3NyJiMzOTsgKFNlcmJpYW4p IHdpbGwgaGF2ZSB0aGUKTWFjcm9sYW5ndWFnZSB2YWx1ZSAmIzM5O3NoJiMzOTsgKFNlcmJvLUNy b2F0aWFuKS48L3A+Cgo8L2Jsb2NrcXVvdGU+Cgo8cD48Yj5bT3RoZXIgY2hhbmdlc108L2I+PC9w PgoKPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0 OyI+Cgo8cD5bU2VhcmNoIGZvciBpbnN0YW5jZXMgb2YgJnF1b3Q7U3VwcHJlc3MtU2NyaXB0JnF1 b3Q7IChqdXN0IGFzIGEgcGxhY2UgdG8KZmluZCB3aGVyZSBmaWVsZCBkZXNjcmlwdGlvbnMgYXJl KSBhbmQgbWFrZSBhbiBhZGRpdGlvbiBvZgomcXVvdDtNYWNyb2xhbmd1YWdlJnF1b3Q7IGlmIGFw cHJvcHJpYXRlLCBlZyBpbiB0aGUgJnF1b3Q7TEFOR1VBR0UgU1VCVEFHClJFR0lTVFJBVElPTiBG T1JNJnF1b3Q7XTwvcD4KCjwvYmxvY2txdW90ZT4KCjxwPjxiciBjbGVhcj0iYWxsIj4KPGJyPgot LSA8YnI+Ck1hcmsgPC9wPgoKPC9zcGFuPjwvZGl2PjwvZGl2PgoKPC9kaXY+Cgo8L2Rpdj4KCgo8 L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPk1hcmsK ------=_Part_48557_15346368.1184430742342-- --===============1285593298== 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 --===============1285593298==-- From ltru-bounces@ietf.org Sat Jul 14 17:47:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pSi-0004Kr-K1; Sat, 14 Jul 2007 17:47:36 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I9pSh-0004Km-KP for ltru-confirm+ok@megatron.ietf.org; Sat, 14 Jul 2007 17:47:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pSh-0004Ke-Az for ltru@ietf.org; Sat, 14 Jul 2007 17:47:35 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9pSd-0005gm-1L for ltru@ietf.org; Sat, 14 Jul 2007 17:47:35 -0400 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 <20070714214729.CKAC22229.mta10.adelphia.net@DGBP7M81> for ; Sat, 14 Jul 2007 21:47:29 +0000 Message-ID: <00fe01c7c660$92e59cf0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 14 Jul 2007 14:47:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Re: Registry change of the day: prefix with more than one 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 Randy Presuhn wrote: >> I believe that we should handle this case under the general rule >> "standards cannot prevent every stupid thing": >> ... >> There does not seem to be similar text in 4646bis. Do we think it >> should be included or is it too paternalistic for readers? > > Since the question seems to keep coming up, it's probably worth > including. For a heading for the section, I like your words: > "standards cannot prevent every stupid thing." My question was what a piece of software should do. Software is notoriously bad at applying wisdom to situations like this. -- 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 Jul 14 19:19:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9qtA-0005oN-Hq; Sat, 14 Jul 2007 19:19:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I9qt9-0005oH-DN for ltru-confirm+ok@megatron.ietf.org; Sat, 14 Jul 2007 19:18:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9qt9-0005o9-30 for ltru@ietf.org; Sat, 14 Jul 2007 19:18:59 -0400 Received: from mta15.adelphia.net ([68.168.78.77]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9qt8-0006UG-OT for ltru@ietf.org; Sat, 14 Jul 2007 19:18:58 -0400 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 <20070714231809.NBUB16178.mta15.adelphia.net@DGBP7M81> for ; Sat, 14 Jul 2007 19:18:09 -0400 Message-ID: <011d01c7c66d$3dbe3900$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 14 Jul 2007 16:18:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Re: Suggested text for future compatibility of registry processors. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > While catching up on my backlog I notice the following note from Mark. > > I would note that we already have a shorter equivalent of this text at > the end of 3.1.2, where it says: > > -- > Future versions of this document might add additional fields to the > registry, so implementations SHOULD ignore fields found in the > registry that are not defined in this document. > -- > > This text was apparently added back in draft-02. Any reason to edit it > some more? This is fine, and the right thing to do for 4646bis, but the point still remains that this wording isn't in place for the current spec, RFC 4646, and so adding new fields will break strictly 4646-conformant processors in the same way that converting the Registry to UTF-8 will. Note that I didn't say either change is a bad thing, or unjustified. -- 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 Jul 14 19:33:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9r6j-0004VJ-Rg; Sat, 14 Jul 2007 19:33:01 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I9r6i-0004VB-J9 for ltru-confirm+ok@megatron.ietf.org; Sat, 14 Jul 2007 19:33:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9r6i-0004V3-9a for ltru@ietf.org; Sat, 14 Jul 2007 19:33:00 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9r6e-0007ta-1y for ltru@ietf.org; Sat, 14 Jul 2007 19:33:00 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1I9r6d-00028S-Qx; Sat, 14 Jul 2007 19:32:55 -0400 Date: Sat, 14 Jul 2007 19:32:55 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Suggested text for future compatibility of registry processors. Message-ID: <20070714233255.GR9402@mercury.ccil.org> References: <011d01c7c66d$3dbe3900$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011d01c7c66d$3dbe3900$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: > This is fine, and the right thing to do for 4646bis, but the point still > remains that this wording isn't in place for the current spec, RFC 4646, > and so adding new fields will break strictly 4646-conformant processors I don't think so. There is no claim in 4646 that there are no other fields. "Be liberal in what you accept" is a general IETF principle. -- John Cowan cowan@ccil.org http://ccil.org/~cowan If I have seen farther than others, it is because I am surrounded by dwarves. --Murray Gell-Mann _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Jul 14 20:16:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9rmu-0000P3-Lm; Sat, 14 Jul 2007 20:16:36 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I9rmt-0000Ot-OV for ltru-confirm+ok@megatron.ietf.org; Sat, 14 Jul 2007 20:16:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9rmt-0000Ol-El for ltru@ietf.org; Sat, 14 Jul 2007 20:16:35 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9rmp-0000Gj-3H for ltru@ietf.org; Sat, 14 Jul 2007 20:16:35 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=NPKQBgp3x/X2C/devrLF60z8gLQTPEcE56wRwE6jQBYMDQ2PYKuJqvbZ0xqUHN+4; 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.164.82.234] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I9rmo-0000Fe-9w for ltru@ietf.org; Sat, 14 Jul 2007 20:16:30 -0400 Message-ID: <000e01c7c675$82d4b5c0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <00fe01c7c660$92e59cf0$6401a8c0@DGBP7M81> Subject: Re: [Ltru] Re: Registry change of the day: prefix with more than onesubtag Date: Sat, 14 Jul 2007 17:17:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888fa44b31bb60a935681c0f3e9ceae2ce07612036de8b91687350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.82.234 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor. > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Saturday, July 14, 2007 2:47 PM > Subject: [Ltru] Re: Registry change of the day: prefix with more than onesubtag ... > My question was what a piece of software should do. Software is > notoriously bad at applying wisdom to situations like this. ... Two cases: when receiving a "stupid" tag, I don't think there's any requirement for software to recognize it as stupid, nor to process it in any special way when we consider the case of software putting a tag on something, I very much doubt that the software is creating these things "generatively". Rather, there is some set of language / region / orthography etc. combinations the software knows about, and for each of these it knows what the tag is. The question of whether a tag would be stupid doesn't arise; it had to be addressed when the set of languages supported was specified. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jul 15 02:03:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9xC8-0006uV-2R; Sun, 15 Jul 2007 02:03:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I9xC6-0006uP-IL for ltru-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 02:02:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9xC6-0006uH-84 for ltru@ietf.org; Sun, 15 Jul 2007 02:02:58 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9xC5-0004BQ-TF for ltru@ietf.org; Sun, 15 Jul 2007 02:02:58 -0400 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 <20070715060221.DMES15912.mta13.adelphia.net@DGBP7M81>; Sun, 15 Jul 2007 02:02:21 -0400 Message-ID: <012f01c7c6a5$b4489e70$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <011d01c7c66d$3dbe3900$6401a8c0@DGBP7M81> <20070714233255.GR9402@mercury.ccil.org> Subject: Re: [Ltru] Re: Suggested text for future compatibility of registry processors. Date: Sat, 14 Jul 2007 23:02:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: >> and so adding new fields will break strictly 4646-conformant >> processors > > I don't think so. There is no claim in 4646 that there are no other > fields. "Be liberal in what you accept" is a general IETF principle. I would have sworn there was such a claim in 4646, but all I can find now is inclusionary wording in Section 3.1: Each record MUST contain the following fields: o 'Type' o Either 'Subtag' or 'Tag' o Description o Added Each record MAY also contain the following fields: o Preferred-Value o Deprecated o Prefix o Comments o Suppress-Script implying (at least to me) that each record MAY NOT contain any other fields. This may not be as strict as I interpret it, but in any case there is no explicit wording (unlike in draft-4646bis) that other fields may be added in the future and should be ignored by processors that don't recognize them. -- 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 Jul 15 02:21:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9xTp-0001H0-Jw; Sun, 15 Jul 2007 02:21:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1I9xTo-00019X-3P for ltru-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 02:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9xTn-00017D-Kz for ltru@ietf.org; Sun, 15 Jul 2007 02:21:15 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9xTj-00065J-B2 for ltru@ietf.org; Sun, 15 Jul 2007 02:21:15 -0400 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 <20070715062110.UGRI12750.mta9.adelphia.net@DGBP7M81>; Sun, 15 Jul 2007 02:21:10 -0400 Message-ID: <013b01c7c6a8$55cb4a20$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 14 Jul 2007 23:21:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Ltru] Re: Macrolanguage and extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > Addision and I have discussed the issue of extlang and Macrolanguages > and are proposing the following text replacing the use of extlang. I won't object to this proposed solution. It is certainly not as bad as some of the alternatives that were mentioned, such as an "Encompasses:" field with 30 or 40 comma-separated language subtags. We have to decide on something and move along. It still floors me that we expect any parsers at all to be able to match "yue" with "zh" but not to be able to pick "en-US" out of "en-Latn-US". And of course all of the grandfathered tags of the form "zh-yue" will now have to be deprecated in favor of "yue", instead of being made redundant. -- 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 Jul 15 11:23:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5wC-0000fD-5M; Sun, 15 Jul 2007 11:23:08 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IA5wA-0000f2-MW for ltru-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 11:23:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5wA-0000et-D1 for ltru@ietf.org; Sun, 15 Jul 2007 11:23:06 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IA5w6-0005U1-4x for ltru@ietf.org; Sun, 15 Jul 2007 11:23:06 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IA5w5-0000ut-Pg; Sun, 15 Jul 2007 11:23:01 -0400 Date: Sun, 15 Jul 2007 11:23:01 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Macrolanguage and extlang Message-ID: <20070715152301.GY9402@mercury.ccil.org> References: <013b01c7c6a8$55cb4a20$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013b01c7c6a8$55cb4a20$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: > >Addision and I have discussed the issue of extlang and Macrolanguages > >and are proposing the following text replacing the use of extlang. > > I won't object to this proposed solution. I don't object to having a Macrolanguage header as such, and even to making it mutable (and therefore informative). I do most strenuously object to upsetting the extlang applecart. Extlangs are a sensible and necessary shim between the 639-2-only world of 4646 and the mixed 639-2/3 world of 4646bis, and I have seen no compelling reasons why they should be discarded. We have been planning them for years, and we should stick to our plan unless there is some hard reason to change it. > It still floors me that we expect any parsers at all to be able to match > "yue" with "zh" but not to be able to pick "en-US" out of "en-Latn-US". > And of course all of the grandfathered tags of the form "zh-yue" will > now have to be deprecated in favor of "yue", instead of being made > redundant. Exactly. -- Possession is said to be nine points of the law, John Cowan but that's not saying how many points the law might have. cowan@ccil.org --Thomas A. Cowan (law professor and my father) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Jul 15 18:21:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IACSo-0003py-5e; Sun, 15 Jul 2007 18:21:14 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IACSl-0003pi-HL for ltru-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 18:21:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IACSl-0003oJ-6a for ltru@ietf.org; Sun, 15 Jul 2007 18:21:11 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IACSd-0003qR-PF for ltru@ietf.org; Sun, 15 Jul 2007 18:21:11 -0400 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 <20070715222029.RBA12750.mta9.adelphia.net@DGBP7M81> for ; Sun, 15 Jul 2007 18:20:29 -0400 Message-ID: <00b801c7c72e$5a033090$6a01a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 15 Jul 2007 15:20:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Re: Macrolanguage and extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 proposed text makes no special arrangement for sign languages, but ties the Macrolanguage field to ISO 639-3 assignments. Shall I assume, using American Sign Language as an example, that the plan is to deprecate "sgn-US" and assign it a Preferred-Value of "ase", but not to give "ase" a Macrolanguage field? %% Type: language Subtag: ase Description: American Sign Language Added: 20xx-xx-xx %% Type: redundant Tag: sgn-US Description: American Sign Language Added: 2001-03-02 Preferred-Value: ase Deprecated: 20xx-xx-xx %% How should people then interpret the existing language subtag "sgn"? -- 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 Jul 15 19:12:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IADGg-000234-MV; Sun, 15 Jul 2007 19:12:46 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IADGf-00022s-HF for ltru-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 19:12:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IADGf-00022k-7R for ltru@ietf.org; Sun, 15 Jul 2007 19:12:45 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IADGa-0007zL-Sf for ltru@ietf.org; Sun, 15 Jul 2007 19:12:45 -0400 Received: by wa-out-1112.google.com with SMTP id k17so1664093waf for ; Sun, 15 Jul 2007 16:12:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=VIx1qycpKJ+5S/+rJs0qeIJ/DbONAZrdFlqGGN4SRviye1DXVWA4wQOcdfg3XVJPlOoZiG9bp4YWic44FWQMqY2s5KEjC73h8FSNoIiJHNLK9NeTpjMohoRRcja1T8qv8UetTmXOx1PhUjzsbV8UvV8yRg/1n40sng5O/wn88bs= 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=Pw6wPhNtijQfGGhGI67vqZCUn5iP4h44GAsqWuzuK67taoEWl/Fvm0I4uvDWLPiR7gnGfpcoY+AdAoX8DpKxnsmEzff0dbFFBqZEkzB4vdDu99i7UOWgGwZu36O8jItdDs9bcpJeSD5Y9qG7TPPFKDx0b752Z1ld6HKXpk1CJp4= Received: by 10.115.78.1 with SMTP id f1mr3631680wal.1184541160105; Sun, 15 Jul 2007 16:12:40 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Sun, 15 Jul 2007 16:12:40 -0700 (PDT) Message-ID: <30b660a20707151612k14b1e578q7cc7887c68ccc785@mail.gmail.com> Date: Sun, 15 Jul 2007 16:12:40 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: Macrolanguage and extlang In-Reply-To: <20070715152301.GY9402@mercury.ccil.org> MIME-Version: 1.0 References: <013b01c7c6a8$55cb4a20$6401a8c0@DGBP7M81> <20070715152301.GY9402@mercury.ccil.org> X-Google-Sender-Auth: 8255a412e6bc9fe2 X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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="===============1252789957==" Errors-To: ltru-bounces@ietf.org --===============1252789957== Content-Type: multipart/alternative; boundary="----=_Part_57870_16065491.1184541160061" ------=_Part_57870_16065491.1184541160061 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > I do most strenuously object to upsetting the extlang applecart. Extlangs > are a sensible and necessary shim between the 639-2-only world of 4646 > and the mixed 639-2/3 world of 4646bis, and I have seen no compelling > reasons why they should be discarded. We have been planning them for > years, and we should stick to our plan unless there is some hard reason > to change it. The main argument I've hear for extlang is behind-the-scenes-inertia. While we made provision in 4646 for possibly accepting them in the future, it was by no means a done-deal. The only reason I've heard advocated for them is that it makes matching easier. But in practice, we have simply not found that to be true. If it is indeed worthwhile to add this mechanism to 4646, a good case needs to be made for it; and inertia isn't a good case. Mark ------=_Part_57870_16065491.1184541160061 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I do most strenuously object to upsetting the extlang applecart.  Extlangs
are a sensible and necessary shim between the 639-2-only world of 4646
and the mixed 639-2/3 world of 4646bis, and I have seen no compelling
reasons why they should be discarded.  We have been planning them for
years, and we should stick to our plan unless there is some hard reason
to change it.

The main argument I've hear for extlang is behind-the-scenes-inertia. While we made provision in 4646 for possibly accepting them in the future, it was by no means a done-deal.

The only reason I've heard advocated for them is that it makes matching easier. But in practice, we have simply not found that to be true. If it is indeed  worthwhile to add this mechanism to 4646, a good case needs to be made for it; and inertia isn't a good case.

Mark

------=_Part_57870_16065491.1184541160061-- --===============1252789957== 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 --===============1252789957==-- From ltru-bounces@ietf.org Sun Jul 15 19:33:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IADac-0005El-8I; Sun, 15 Jul 2007 19:33:22 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IADab-0005BM-Co for ltru-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 19:33:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IADab-0005BE-3O for ltru@ietf.org; Sun, 15 Jul 2007 19:33:21 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IADaW-00008m-Ni for ltru@ietf.org; Sun, 15 Jul 2007 19:33:21 -0400 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 <20070715233315.OUJF22229.mta10.adelphia.net@DGBP7M81>; Sun, 15 Jul 2007 23:33:15 +0000 Message-ID: <00d701c7c738$841e6930$6a01a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <013b01c7c6a8$55cb4a20$6401a8c0@DGBP7M81> <20070715152301.GY9402@mercury.ccil.org> <30b660a20707151612k14b1e578q7cc7887c68ccc785@mail.gmail.com> Subject: Re: [Ltru] Re: Macrolanguage and extlang Date: Sun, 15 Jul 2007 16:33:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 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 Mark Davis wrote: > The main argument I've hear for extlang is behind-the-scenes-inertia. > While we made provision in 4646 for possibly accepting them in the > future, it was by no means a done-deal. The main argument that has been offered is that it makes matching easier. Whether that argument was heard is a different question. > The only reason I've heard advocated for them is that it makes > matching easier. But in practice, we have simply not found that to be > true. If it is indeed worthwhile to add this mechanism to 4646, a > good case needs to be made for it; and inertia isn't a good case. Here is the argument restated. It is based not on behind-the-scenes inertia, but on backward compatibility, the exact same issue that caused us to adopt Suppress-Script. Existing Cantonese text has been tagged as "zh", the basic ISO 639-1-based tag, or as "zh-yue", the tag that was registered for this purpose back in 1999. The extlang mechanism would have established "yue" as an extlang under "zh", so the proper tagging of Cantonese would continue to be "zh" (more general) or "zh-yue" (more specific). Matching engines would continue to operate as they do now. The proposed mechanism establishes "yue" as a primary language subtag, so the proper tagging of Cantonese becomes "yue". Matching engines must be upgraded to RFC 4646bis in order to have any chance at finding a match. The much-beloved and much-catered-to RFC 3066 remove-from-right "fallback" algorithm will NEVER find a match between "yue" and "zh", regardless of whether script and/or region subtags are involved. Put another way: Extlangs may not make matching easier, but *not* having extlangs will make matching harder. -- 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 Jul 16 05:20:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMl8-0005RP-5w; Mon, 16 Jul 2007 05:20:50 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IAMl6-0005RF-3u for ltru-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 05:20:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMl5-0005R7-NR for ltru@ietf.org; Mon, 16 Jul 2007 05:20:47 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAMl1-0003Ya-Df for ltru@ietf.org; Mon, 16 Jul 2007 05:20:47 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id D0F521C0092; Mon, 16 Jul 2007 11:20:42 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id CC84D1C0090; Mon, 16 Jul 2007 11:20:42 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id BEF4458ECAE; Mon, 16 Jul 2007 11:20:42 +0200 (CEST) Date: Mon, 16 Jul 2007 11:20:42 +0200 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20070716092042.GA9841@nic.fr> References: <30b660a20707131806o19919cc7v97cc82f3eada43ff@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20707131806o19919cc7v97cc82f3eada43ff@mail.gmail.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-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: d17f825e43c9aed4fd65b7edddddec89 Cc: LTRU Working Group Subject: [Ltru] Re: Macrolanguage and extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Jul 13, 2007 at 06:06:03PM -0700, Mark Davis wrote a message of 172 lines which said: > For example, in a given application the best fallback for "be" > (Breton), may be "fr" (French) -- rather than the more closely > related "cy" (Welsh) -- because Breton readers are far more likely > to be able to read French than Welsh. Good example but Breton is "br"... _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jul 16 05:25:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMpX-0007II-IF; Mon, 16 Jul 2007 05:25:23 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IAMpV-0007IB-Ki for ltru-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 05:25:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMpV-0007I3-A7 for ltru@ietf.org; Mon, 16 Jul 2007 05:25:21 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAMpR-0003cW-0E for ltru@ietf.org; Mon, 16 Jul 2007 05:25:21 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id A32381C00E3; Mon, 16 Jul 2007 11:25:16 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 9ECFC1C00E0; Mon, 16 Jul 2007 11:25:16 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 9A47E58ECD1; Mon, 16 Jul 2007 11:25:16 +0200 (CEST) Date: Mon, 16 Jul 2007 11:25:16 +0200 From: Stephane Bortzmeyer To: Don Osborn Message-ID: <20070716092516.GB9841@nic.fr> References: <30b660a20707131806o19919cc7v97cc82f3eada43ff@mail.gmail.com> <001001c7c612$30a30710$91e91530$@net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001001c7c612$30a30710$91e91530$@net> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'LTRU Working Group' Subject: [Ltru] Re: Macrolanguage and extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 Sat, Jul 14, 2007 at 08:26:21AM -0400, Don Osborn wrote a message of 524 lines which said: > The fallback language issue (mentioned in the example re Breton) > raises another question: can there be more than one fallback > language? In the case of many of the crossborder languages in > Africa (such as Hausa, Swahili, Wolof, Fula, Tsonga, Oshiwambo, > etc.) this would be helpful. Breton was just an example and I do not think that anyone suggested to add such information in the registry. It would require a lot of work, anyway. Case in point: you're in Helsinski (Finland) and you want to ask someone something. You do not speak Finnish. What do you try? * Swedish (administrative best fit, since it is the second official language in Finland), * Hungarian (linguistic best fit, since it is the closest language), * English (practical best fit, since it is probably the best fallback, in practice). Trying to make a registry of such "best fits" is a work of a size comparable to ISO 639. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jul 16 05:31:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMvK-0005Oj-Bv; Mon, 16 Jul 2007 05:31:22 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IAMvI-0005Oc-W5 for ltru-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 05:31:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMvI-0005OT-Me for ltru@ietf.org; Mon, 16 Jul 2007 05:31:20 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAMvE-0003jD-D3 for ltru@ietf.org; Mon, 16 Jul 2007 05:31:20 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 0DF3D1C00E3; Mon, 16 Jul 2007 11:31:16 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 08A631C00E0; Mon, 16 Jul 2007 11:31:16 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id ED8A358ECAE; Mon, 16 Jul 2007 11:31:15 +0200 (CEST) Date: Mon, 16 Jul 2007 11:31:15 +0200 From: Stephane Bortzmeyer To: John Cowan Message-ID: <20070716093115.GC9841@nic.fr> References: <011d01c7c66d$3dbe3900$6401a8c0@DGBP7M81> <20070714233255.GR9402@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070714233255.GR9402@mercury.ccil.org> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.6 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: LTRU Working Group Subject: [Ltru] Re: Suggested text for future compatibility of registry processors. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 Sat, Jul 14, 2007 at 07:32:55PM -0400, John Cowan wrote a message of 19 lines which said: > "Be liberal in what you accept" is a general IETF principle. And not always a good one, specially in the case of the LSR where there is just one supplier of data. Being liberal when you accept stuff from many unknown clients is one thing, when there is only one, the IANA, I doubt it is a good idea. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jul 16 05:33:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMxh-0007CM-NZ; Mon, 16 Jul 2007 05:33:49 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IAMxg-0007CE-UL for ltru-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 05:33:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMxg-0007C6-Kp for ltru@ietf.org; Mon, 16 Jul 2007 05:33:48 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAMxc-0003lZ-BT for ltru@ietf.org; Mon, 16 Jul 2007 05:33:48 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 048EC1C00DA; Mon, 16 Jul 2007 11:33:44 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 002DA1C0092; Mon, 16 Jul 2007 11:33:44 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id E69FD58ECAE; Mon, 16 Jul 2007 11:33:43 +0200 (CEST) Date: Mon, 16 Jul 2007 11:33:43 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20070716093343.GD9841@nic.fr> References: <013b01c7c6a8$55cb4a20$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013b01c7c6a8$55cb4a20$6401a8c0@DGBP7M81> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-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: cf4fa59384e76e63313391b70cd0dd25 Cc: LTRU Working Group Subject: [Ltru] Re: Macrolanguage and extlang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 Sat, Jul 14, 2007 at 11:21:09PM -0700, Doug Ewell wrote a message of 28 lines which said: > It is certainly not as bad as some of the alternatives that were > mentioned, such as an "Encompasses:" field with 30 or 40 > comma-separated language subtags. We have to decide on something > and move along. Speaking as someone who likes databases, I can say it seems better to have the information in the "encompassed language" record rather than in the "macrolanguage" record. That way, adding a record will not require to modify *another* record. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jul 16 11:52:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IASs4-0005TE-N8; Mon, 16 Jul 2007 11:52:24 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IASs3-0005T6-Gw for ltru-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 11:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IASs3-0005Sy-7P for ltru@ietf.org; Mon, 16 Jul 2007 11:52:23 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IASry-0000R4-SW for ltru@ietf.org; Mon, 16 Jul 2007 11:52:23 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 16 Jul 2007 08:52:18 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Mon, 16 Jul 2007 08:52:16 -0700 From: Peter Constable To: LTRU Working Group Date: Mon, 16 Jul 2007 08:52:21 -0700 Subject: RE: [Ltru] Re: Macrolanguage and extlang Thread-Topic: [Ltru] Re: Macrolanguage and extlang Thread-Index: AcfHOInSie+xawurRiqXq8VKFSVaDgAgQz0w Message-ID: References: <013b01c7c6a8$55cb4a20$6401a8c0@DGBP7M81> <20070715152301.GY9402@mercury.ccil.org> <30b660a20707151612k14b1e578q7cc7887c68ccc785@mail.gmail.com> <00d701c7c738$841e6930$6a01a8c0@DGBP7M81> In-Reply-To: <00d701c7c738$841e6930$6a01a8c0@DGBP7M81> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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's not clear to me why matching (A) zh-Hans-CN with zh-yue-Hans-CN is much harder than matching (B) zh-Hans-CN with yue-Hans-CN. In the (B) case, you need to treat "zh" and "yue" as a match at some level.= In the (A) case, you need to treat "zh" and "zh-yue" as a match at that sa= me level. The only added work for (A) is that you need to recognize "zh-yue= " as the entity to be compared. But then, for (B) you still need to recogni= ze that "yue" may match something other than "yue". There is some extra wor= k either way. The RFC 1766/3066 remove-from-right algorithm won't get a match in case (A)= , but neither will it do so in case (B). At least with the approach used in= (A), it will match zh and zh-yue, whereas it won't match zh and yue, as Do= ug pointed out. On the other hand... It's not clear how important the zh/zh-yue versus zh/yue example is for Chi= nese: it makes an valid argument against (B) if existing content is tagged = "zh-yue"/"zh-yue-Han?" and a language range "zh" is used, but says nothing = about cases of content tagged "zh"/"zh-Han?"/"zh-??" and a language range "= zh-yue". If we're concerned about legacy content created before the extlang= "yue" was introduced, that would be the latter. Mark's and Addison's proposal does have a couple of points in its favour --= these may or may not be significant: - Whereas using an extlang in a case like "zh-yue" was easy to consider, no= t all other cases will necessarily be as easy. (Clearly we don't want to in= troduce macrolanguage/extlang pairs for Norwegian or Serbo-Croatian, but I = think we've assumed all along these can be treated as grandfathered cases.)= Mark's proposal means we're never required to consider whether "xxx-yyy" i= s really helpful: we just always use "yyy". - If there's ever a case in which ISO 639 has related languages "xxx" and "= yyy" and a new macrolanguage "mmm" encompassing the two is later added, we = don't need to retag existing content as "mmm-xxx" and "mmm-yyy", nor do we = need to do any special-case processing with the registry to keep "mmm-xxx" = and "mmm-yyy" from being used. And neither do implementers need to introduc= e new mechanisms to get appropriate matches between "mmm" and "xxx"/"yyy" s= ince, under M&A's proposal, they already would have a general mechanism in = their matching process for this; all they need is to incorporate the new da= ta. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Jul 16 13:40:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUYm-0005zJ-G0; Mon, 16 Jul 2007 13:40:36 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IAUYl-0005xh-Hu for ltru-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 13:40:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUYl-0005vA-5w for ltru@ietf.org; Mon, 16 Jul 2007 13:40:35 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAUYf-0004PK-TX for ltru@ietf.org; Mon, 16 Jul 2007 13:40:35 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IAUYe-0002JB-20; Mon, 16 Jul 2007 13:40:28 -0400 Date: Mon, 16 Jul 2007 13:40:28 -0400 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: Macrolanguage and extlang Message-ID: <20070716174027.GC15231@mercury.ccil.org> References: <30b660a20707131806o19919cc7v97cc82f3eada43ff@mail.gmail.com> <001001c7c612$30a30710$91e91530$@net> <20070716092516.GB9841@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070716092516.GB9841@nic.fr> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Stephane Bortzmeyer scripsit: > * Hungarian (linguistic best fit, since it is the closest language), In fact the closest relatives of Finnish are Estonian and various minority languages of Russia, Latvia, Norway, and Sweden, comprising the Finnic branch of the Uralic language family. Hungarian belongs to the Ugric branch, which is maximally distant from the Finnic branch. So this is like comparing English to Hindi and skipping over Scots, Frisian, and Dutch. See http://www.ethnologue.com/show_family.asp?subid=90210 . -- Overhead, without any fuss, the stars were going out. --Arthur C. Clarke, "The Nine Billion Names of God" John Cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 17 13:07:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAqWL-0006IA-4f; Tue, 17 Jul 2007 13:07:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IAqWJ-0006Dl-Rw for ltru-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 13:07:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAqWJ-0006Dd-HN for ltru@ietf.org; Tue, 17 Jul 2007 13:07:31 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAqWI-0007ma-4E for ltru@ietf.org; Tue, 17 Jul 2007 13:07:31 -0400 Received: from [10.72.73.49] (snvvpn1-10-72-73-c49.corp.yahoo.com [10.72.73.49]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l6HH7Omc080471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2007 10:07:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=IqezRFJjpSrB6qWLtyWuQNUDkj6cDy+hpvTxUyMw0ppkCwpbG1jFS8FOLa94ThZT Message-ID: <469CF74C.9070103@yahoo-inc.com> Date: Tue, 17 Jul 2007 10:07:24 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ltru] Updated draft-4646bis... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All, I have just completed and posted my edits to draft-07. I have not yet submitted them to the ID Editor... as Martin points out, the integer burning forge is currently on hiatus, pending IETF #69. However, the edits are all in place and can be used to further the discussion. Note that I have not incorporated the proposed text related to Macrolanguage. However I have incorporated my proposed UTF-8 changes. A diff from draft-06 can be accessed here: http://tinyurl.com/2o7t6m The documents posted are: http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.html http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.txt http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.xml Happy commenting. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 Jul 17 14:01:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArMY-00040N-B0; Tue, 17 Jul 2007 14:01:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IArMX-00040H-8b for ltru-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:01:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArMW-000409-UI for ltru@ietf.org; Tue, 17 Jul 2007 14:01:28 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IArMT-00015m-HY for ltru@ietf.org; Tue, 17 Jul 2007 14:01:28 -0400 Received: from c83-248-102-190.bredband.comhem.se ([83.248.102.190]:4946 helo=wgbgkka02x) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.66) (envelope-from ) id 1IArMP-0006OQ-7g; Tue, 17 Jul 2007 20:01:23 +0200 From: "Kent Karlsson" To: "'John Cowan'" , "'Stephane Bortzmeyer'" References: <30b660a20707131806o19919cc7v97cc82f3eada43ff@mail.gmail.com><001001c7c612$30a30710$91e91530$@net><20070716092516.GB9841@nic.fr> <20070716174027.GC15231@mercury.ccil.org> Subject: RE: [Ltru] Re: Macrolanguage and extlang Date: Tue, 17 Jul 2007 20:00:52 +0200 Message-ID: <001d01c7c89c$7b890860$be66f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfH0G2kIew05/EDRmWcqHr+o8afGAAyohAg In-Reply-To: <20070716174027.GC15231@mercury.ccil.org> X-Originating-IP: 83.248.102.190 X-Scan-Result: No virus found in message 1IArMP-0006OQ-7g. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1IArMP-0006OQ-7g 10bdf0b77debc5008bbb6384fc0ae213 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Stephane Bortzmeyer scripsit: > > > * Hungarian (linguistic best fit, since it is the closest language), > > In fact the closest relatives of Finnish are Estonian and various > minority languages of Russia, Latvia, Norway, and Sweden, comprising > the Finnic branch of the Uralic language family. Hungarian belongs to > the Ugric branch, which is maximally distant from the Finnic branch. > So this is like comparing English to Hindi and skipping over Scots, > Frisian, and Dutch. > > See http://www.ethnologue.com/show_family.asp?subid=90210 . I would give more credibility to http://en.wikipedia.org/wiki/Finno-ugric. Sami languages are closely related to Finnish, which is not reflected in the Ethnologue page but is reflected in the Wikipedia page), Hungarian is quite distant from the Finnic languages; English/Hindi is a good comparison. See the second paragraph of that Wikipedia page. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Jul 17 14:22:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArgZ-0004UB-Ag; Tue, 17 Jul 2007 14:22:11 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IArgX-0004TV-LL for ltru-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:22:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArgV-0004T8-TA for ltru@ietf.org; Tue, 17 Jul 2007 14:22:09 -0400 Received: from nz-out-0506.google.com ([64.233.162.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IArgU-0001rx-ED for ltru@ietf.org; Tue, 17 Jul 2007 14:22:07 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1198661nzf for ; Tue, 17 Jul 2007 11:22:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=K9nI4PsmyqDzcvxfPriIgwdMicMeSyxOcIz/apk++2u1IYSwVLNH8KQSKJ/e5d+ETaAl5ywcDPKlkoKO+rvhR63zIdDRVvSjCOB9W546R/0kdmcqCc+C/uZLv8MhC/1eu0t7ipn7u9TXdHAS7Xo3pb3oopMMdTfboqtlFh69AQg= 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=c3JJL4KQP+erCjnRtMRh/9NwNBRPodXVZjLhRyO12nvbp1IcD2Tn30rggFiP4qpxleRvx5rlnSvdCDASsRhWJ9TN7bp2i4/loqjc56tpnNM+5CAqxHsOdnQwoxOA1f1+fGBbOJ8uTDfF7SJsk0fnvdyZRQuzhYtzAMj9YrwRzDk= Received: by 10.114.26.1 with SMTP id 1mr656463waz.1184696524676; Tue, 17 Jul 2007 11:22:04 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Tue, 17 Jul 2007 11:21:59 -0700 (PDT) Message-ID: <30b660a20707171121h48c29bf4l761f108014d06ca4@mail.gmail.com> Date: Tue, 17 Jul 2007 11:21:59 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Updated draft-4646bis... In-Reply-To: <469CF74C.9070103@yahoo-inc.com> MIME-Version: 1.0 References: <469CF74C.9070103@yahoo-inc.com> X-Google-Sender-Auth: 3b5aed6e29ebfc5d X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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="===============0993533294==" Errors-To: ltru-bounces@ietf.org --===============0993533294== Content-Type: multipart/alternative; boundary="----=_Part_89872_14491559.1184696519569" ------=_Part_89872_14491559.1184696519569 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't see the following in the text, although I believe there was rough consensus. You have something there, but the language is not nearly forceful enough). The 'mis' (Uncoded) primary language subtag SHOULD NOT be used. According to ISO 639, it is used to identify linguistic content whose language is known but which does not *currently* have a corresponding subtag. It is thus intrinsically unstable -- the addition of other codes in the future can render its application invalid at any point without any warning -- and hence incompatible with the stability goals of BCP 47. It is thus always preferable to use other subtags: either "und" or -- with prior agreement -- private use subtags. See: date Jun 16, 2007 8:29 AM subject Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis") Mark On 7/17/07, Addison Phillips wrote: > > All, > > I have just completed and posted my edits to draft-07. I have not yet > submitted them to the ID Editor... as Martin points out, the integer > burning forge is currently on hiatus, pending IETF #69. > > However, the edits are all in place and can be used to further the > discussion. Note that I have not incorporated the proposed text related > to Macrolanguage. However I have incorporated my proposed UTF-8 changes. > > A diff from draft-06 can be accessed here: > > http://tinyurl.com/2o7t6m > > The documents posted are: > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.html > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.txt > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.xml > > Happy commenting. > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_89872_14491559.1184696519569 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't see the following in the text, although I believe there was rough consensus. You have something there, but the language is not nearly forceful enough).

The ' mis' (Uncoded) primary language subtag SHOULD NOT be used. According to ISO 639, it is used to identify linguistic content whose language is known but which does not *currently* have a corresponding subtag. It is thus intrinsically unstable -- the addition of other codes in the future can render its application invalid at any point without any warning -- and hence incompatible with the stability goals of BCP 47. It is thus always preferable to use other subtags: either "und" or -- with prior agreement -- private use subtags.

See:


date
 Jun 16, 2007 8:29 AM 

subject
Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")


Mark

On 7/17/07, Addison Phillips <addison@yahoo-inc.com> wrote:
All,

I have just completed and posted my edits to draft-07. I have not yet
submitted them to the ID Editor... as Martin points out, the integer
burning forge is currently on hiatus, pending IETF #69.

However, the edits are all in place and can be used to further the
discussion. Note that I have not incorporated the proposed text related
to Macrolanguage. However I have incorporated my proposed UTF-8 changes.

A diff from draft-06 can be accessed here:

   http://tinyurl.com/2o7t6m

The documents posted are:

   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.html
   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.txt
   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.xml

Happy commenting.

Addison

--
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.


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



--
Mark ------=_Part_89872_14491559.1184696519569-- --===============0993533294== 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 --===============0993533294==-- From ltru-bounces@ietf.org Tue Jul 17 14:31:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArpx-0006mj-Tr; Tue, 17 Jul 2007 14:31:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IArpv-0006bO-Mc for ltru-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:31:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArpv-0006aF-9t for ltru@ietf.org; Tue, 17 Jul 2007 14:31:51 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IArps-0002Ze-Sp for ltru@ietf.org; Tue, 17 Jul 2007 14:31:51 -0400 Received: from [10.72.73.49] (snvvpn1-10-72-73-c49.corp.yahoo.com [10.72.73.49]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l6HIVTwW014867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 11:31:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=sMF6ALsIk7nIwvN/hWueYxc0CSSxuBcgcB2+BdwazeLHO3JjfKTyPh6MStBMrnVF Message-ID: <469D0B00.4050908@yahoo-inc.com> Date: Tue, 17 Jul 2007 11:31:28 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Updated draft-4646bis... References: <469CF74C.9070103@yahoo-inc.com> <30b660a20707171121h48c29bf4l761f108014d06ca4@mail.gmail.com> In-Reply-To: <30b660a20707171121h48c29bf4l761f108014d06ca4@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 The text in the editor's copy, btw is: -- The 'mis' (Uncoded) primary language subtag is used to identify linguistic content whose language is known but for which no subtag has been defined. It is intended for use languages not otherwise categorized or in cases in which the range of subtags is constrained. It SHOULD NOT be used except when other means of identifying the language are not available. For example, a library application might limit the list of subtags to those associated with the codes defined by the [MARC21] standard. The 'mis' subtag might be used by this application for languages not included in that set. -- I note that your text is what I said I would put into the I-D, in this message: http://article.gmane.org/gmane.ietf.ltru/8019 Must have missed it in cleanup. Addiso Mark Davis wrote: > I don't see the following in the text, although I believe there was > rough consensus. You have something there, but the language is not > nearly forceful enough). > > The ' mis' (Uncoded) primary language subtag SHOULD NOT be used. > According to ISO 639, it is used to identify linguistic content whose > language is known but which does not *currently* have a corresponding > subtag. It is thus intrinsically unstable -- the addition of other codes > in the future can render its application invalid at any point without > any warning -- and hence incompatible with the stability goals of BCP > 47. It is thus always preferable to use other subtags: either "und" or > -- with prior agreement -- private use subtags. > > See: > > > date > Jun 16, 2007 8:29 AM > > subject > Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis") > > > > Mark > > On 7/17/07, *Addison Phillips* > wrote: > > All, > > I have just completed and posted my edits to draft-07. I have not yet > submitted them to the ID Editor... as Martin points out, the integer > burning forge is currently on hiatus, pending IETF #69. > > However, the edits are all in place and can be used to further the > discussion. Note that I have not incorporated the proposed text related > to Macrolanguage. However I have incorporated my proposed UTF-8 changes. > > A diff from draft-06 can be accessed here: > > http://tinyurl.com/2o7t6m > > The documents posted are: > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.html > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.txt > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.xml > > Happy commenting. > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > -- > Mark -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 Jul 17 14:41:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArzE-0003A0-97; Tue, 17 Jul 2007 14:41:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IArzD-00039q-7j for ltru-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:41:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArzC-00039h-TG for ltru@ietf.org; Tue, 17 Jul 2007 14:41:26 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IArzB-0003J1-Dv for ltru@ietf.org; Tue, 17 Jul 2007 14:41:26 -0400 Received: from [10.72.73.49] (snvvpn1-10-72-73-c49.corp.yahoo.com [10.72.73.49]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l6HIf5KP016026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 11:41:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=v+LiWe0ZQ2cQR0x4/vAm5ky/aXimSKdBNX+B0K0PWIXyvs7YGVvqvChqg2jrE+3/ Message-ID: <469D0D41.8000202@yahoo-inc.com> Date: Tue, 17 Jul 2007 11:41:05 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Updated draft-4646bis... References: <469CF74C.9070103@yahoo-inc.com> <30b660a20707171121h48c29bf4l761f108014d06ca4@mail.gmail.com> In-Reply-To: <30b660a20707171121h48c29bf4l761f108014d06ca4@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 NB> In inserting this text, I edited it for flow and formatting. I eliminated some redundant (and, in my view, slightly hyperbolic) text. The inserted text reads: -- The 'mis' (Uncoded) primary language subtag identifies content whose language is known but which does not currently have a corresponding subtag. This subtag SHOULD NOT be used. Because the addition of other codes in the future can render its application invalid, it is inherently unstable and hence incompatible with the stability goals of BCP 47. It is always preferable to use other subtags: either 'und' or (with prior agreement) private use subtags. -- I moved the definition to the first sentence so that this item is more like the surrounding items. Addison Mark Davis wrote: > I don't see the following in the text, although I believe there was > rough consensus. You have something there, but the language is not > nearly forceful enough). > > The ' mis' (Uncoded) primary language subtag SHOULD NOT be used. > According to ISO 639, it is used to identify linguistic content whose > language is known but which does not *currently* have a corresponding > subtag. It is thus intrinsically unstable -- the addition of other codes > in the future can render its application invalid at any point without > any warning -- and hence incompatible with the stability goals of BCP > 47. It is thus always preferable to use other subtags: either "und" or > -- with prior agreement -- private use subtags. > > See: > > > date > Jun 16, 2007 8:29 AM > > subject > Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis") > > > > Mark > > On 7/17/07, *Addison Phillips* > wrote: > > All, > > I have just completed and posted my edits to draft-07. I have not yet > submitted them to the ID Editor... as Martin points out, the integer > burning forge is currently on hiatus, pending IETF #69. > > However, the edits are all in place and can be used to further the > discussion. Note that I have not incorporated the proposed text related > to Macrolanguage. However I have incorporated my proposed UTF-8 changes. > > A diff from draft-06 can be accessed here: > > http://tinyurl.com/2o7t6m > > The documents posted are: > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.html > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.txt > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.xml > > Happy commenting. > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > -- > Mark -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 Jul 17 14:53:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsAi-0005lH-Vz; Tue, 17 Jul 2007 14:53:20 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IAsAg-0005lC-4Y for ltru-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:53:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsAe-0005ky-DI for ltru@ietf.org; Tue, 17 Jul 2007 14:53:17 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAsAb-0003mO-Uq for ltru@ietf.org; Tue, 17 Jul 2007 14:53:16 -0400 Received: from [10.72.73.49] (snvvpn1-10-72-73-c49.corp.yahoo.com [10.72.73.49]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l6HIr4XM093033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2007 11:53:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=Wowj0f/bQH/lrUJ3+U5NJRWuMg5uOCnWKOjzhp8s/z8xkBCy2A6QpTZa/82TAA0X Message-ID: <469D1010.3000805@yahoo-inc.com> Date: Tue, 17 Jul 2007 11:53:04 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ltru] examples of registration form... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All, In editing today I noticed again that Section 3.3 (Maintenance of the Registry) contains an example registration form. http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.html#maintreg This is annoying in part because the actual registration form is not introduced until Section 3.5. Section 3.3 also repeats a number of things that appear in Section 3.5. I propose to do the following: 1. Remove the example form from Section 3.3, along with the preceding paragraph. Note that this information is already in Section 3.5. 2. Move the two paragraphs following the form to Section 3.5. 3. Move the three paragraphs now at the end of Section 3.3 (I moved them there sometime during draft-07's gestation) to Section 3.4 (Stability), since they deal with the stability of the grandfathered/redundant set. 4. Add two or three examples to a new document appendix of registration forms. Thoughts? Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 Jul 17 15:19:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsaM-00026J-I2; Tue, 17 Jul 2007 15:19:50 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IAsaL-000268-4B for ltru-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 15:19:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsaK-00025y-Qh for ltru@ietf.org; Tue, 17 Jul 2007 15:19:48 -0400 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAsaJ-0004mW-E9 for ltru@ietf.org; Tue, 17 Jul 2007 15:19:48 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1213869nzf for ; Tue, 17 Jul 2007 12:19:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Fk+oV7Jyn7sXwbXhVWplUWn9MqEOJznWHZXqeLEQyc8CS+BMRdc0emlATSjQ2Fet6svvnJFuwXgCDSMeV46Jc016dqEi2VX4Elgt27gEXoDDUYOgGye53TVK6b84nkOEmfP5c6KVPiNsLqcqPH/U3DWnkOuIUsN8vEgtKhp6yUM= 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=PqSm7kKCfy7A50ScVxI1uchN9JuLB2AmyL+w7S55TUZrOCQ7/gAT+nNK6pGQfYap8aXkQb2JHEBxItjSo19N9blWFQ+OlQ7x5pcPrTVocntRJz4g4TbG76TOOrx/4DyZ8r/iracSgbAL5IVymkGF8HUQBSTjiHmDiHNY4lDQFgw= Received: by 10.114.88.1 with SMTP id l1mr714415wab.1184699986526; Tue, 17 Jul 2007 12:19:46 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Tue, 17 Jul 2007 12:19:46 -0700 (PDT) Message-ID: <30b660a20707171219q4c824654h7ad9063f23ba26ad@mail.gmail.com> Date: Tue, 17 Jul 2007 12:19:46 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Macrolanguage and extlang In-Reply-To: <00d701c7c738$841e6930$6a01a8c0@DGBP7M81> MIME-Version: 1.0 References: <013b01c7c6a8$55cb4a20$6401a8c0@DGBP7M81> <20070715152301.GY9402@mercury.ccil.org> <30b660a20707151612k14b1e578q7cc7887c68ccc785@mail.gmail.com> <00d701c7c738$841e6930$6a01a8c0@DGBP7M81> X-Google-Sender-Auth: e98a2f4e3601165b X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 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="===============1771091650==" Errors-To: ltru-bounces@ietf.org --===============1771091650== Content-Type: multipart/alternative; boundary="----=_Part_91054_20103429.1184699986433" ------=_Part_91054_20103429.1184699986433 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I just find your position hard to understand, perhaps you can help me. Maybe some scenarios would help. Suppose that: - My site has support for zh, zh-Hans, and zh-Hant. zh = Mandarin since that is what everyone means by "zh" currently. As is customary in fallback, the content of zh is the predominent form (zh-Hans) [this is just for example; if a TW site has a different convention alternate examples can be given. - A user comes in with different requests, listed below. Scenario 1. The user's browser has the proposed "zh-yue-Hant-US". My lookup falls back to zh, so I serve it up to the user. So even if the target of the match (zh) is not Cantonese, you want a fallback to zh. I'm guessing that you see this as better than if we defined the tag as "yue-Hant-US", since it gets to some fallback that the user is likely to understand. But I don't see this as much different than if we had fr-br-BE (meaning Breton, but fall back to French), or ro-mo (meaning Moldavian, but falling back to Romanian). And note that in the fallback, the script and region are completely lost. Scenario 2. The user's browser has zh-cmn-Hant-US. In matching, we fall back to zh. Note than in the fallback, the script and region are completely lost. We have essentially just introduced a synonym for zh which causes fallback to lose information, for no good reason. The problem with extlang is that the fallback from encompassed language to macrolanguage is fundamentally different in kind than a fallback from region to script to base language. In the case of script, like uz-Arab and uz-Latn, or en-US vs en-GB, we really have variations on the same language, and fallback makes sense. We ordered the subtags so that it works optimally overall. The encompassed languages, on the other hand, are not just dialects, not just variants. They are languages in their own right. Trying to insert them into the fallback process just screws things up, because they need a "sideways" matching not just simple truncation fallback. If you want to do any fallback with extlang, it would be to fall back from zh-yue- to zh-. That means that in order to do reasonable fallback, you can't just use truncation fallback anyway. So I see the situation this way: 1. The only reason for adding the complication of the extlang mechanism is to make truncation fallback work better. 2. Truncation fallback with extlang doesn't work better. 3. So there is no need to make encompassed languages be "secondary" languages by making them be "secondary" subtags. The goals of extlang are good, to make matching work better, but in practice it just makes things worse. [Speaking to those familiar with C++, it feels a bit like the default assignment operator in C++. Nice in theory, but in practice it gums things up more than it fixes, since once you are beyond very simple (toy) classes, the default is almost always wrong -- but because it is supplied behind your back you don't realize it.] So instead of adding the extlang mechanism to RFC 4646, what we really need to do is to point people to how to handle yue and other encompassed languages along with mo/ro, tl/fil, and other edge cases in a reasonable way, by augmenting matching. Mark On 7/15/07, Doug Ewell wrote: > > Mark Davis wrote: > > > The main argument I've hear for extlang is behind-the-scenes-inertia. > > While we made provision in 4646 for possibly accepting them in the > > future, it was by no means a done-deal. > > The main argument that has been offered is that it makes matching > easier. Whether that argument was heard is a different question. > > > The only reason I've heard advocated for them is that it makes > > matching easier. But in practice, we have simply not found that to be > > true. If it is indeed worthwhile to add this mechanism to 4646, a > > good case needs to be made for it; and inertia isn't a good case. > > Here is the argument restated. It is based not on behind-the-scenes > inertia, but on backward compatibility, the exact same issue that caused > us to adopt Suppress-Script. > > Existing Cantonese text has been tagged as "zh", the basic ISO > 639-1-based tag, or as "zh-yue", the tag that was registered for this > purpose back in 1999. > > The extlang mechanism would have established "yue" as an extlang under > "zh", so the proper tagging of Cantonese would continue to be "zh" (more > general) or "zh-yue" (more specific). Matching engines would continue > to operate as they do now. > > The proposed mechanism establishes "yue" as a primary language subtag, > so the proper tagging of Cantonese becomes "yue". Matching engines must > be upgraded to RFC 4646bis in order to have any chance at finding a > match. The much-beloved and much-catered-to RFC 3066 remove-from-right > "fallback" algorithm will NEVER find a match between "yue" and "zh", > regardless of whether script and/or region subtags are involved. > > Put another way: Extlangs may not make matching easier, but *not* having > extlangs will make matching harder. > > -- > 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 > > -- Mark ------=_Part_91054_20103429.1184699986433 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I just find your position hard to understand, perhaps you can help me. Maybe some scenarios would help.

Suppose that:
  • My site has support for zh, zh-Hans, and zh-Hant. zh = Mandarin since that is what everyone means by "zh" currently. As is customary in fallback, the content of zh is the predominent form (zh-Hans) [this is just for example; if a TW site has a different convention alternate examples can be given.
  • A user comes in with different requests, listed below.

Scenario 1. The user's browser has the proposed "zh-yue-Hant-US". My lookup falls back to zh, so I serve it up to the user. So even if the target of the match (zh) is not Cantonese, you want a fallback to zh. I'm guessing that you see this as better than if we defined the tag as "yue-Hant-US", since it gets to some fallback that the user is likely to understand. But I don't see this as much different than if we had fr-br-BE (meaning Breton, but fall back to French), or ro-mo (meaning Moldavian, but falling back to Romanian). And note that in the fallback, the script and region are completely lost.

Scenario 2. The user's browser has zh-cmn-Hant-US. In matching, we fall back to zh. Note than in the fallback, the script and region are completely lost. We have essentially just introduced a synonym for zh which causes fallback to lose information, for no good reason.


The problem with extlang is that the fallback from encompassed language to macrolanguage is fundamentally different in kind than a fallback from region to script to base language. In the case of script, like uz-Arab and uz-Latn, or en-US vs en-GB, we really have variations on the same language, and fallback makes sense. We ordered the subtags so that it works optimally overall.

The encompassed languages, on the other hand, are not just dialects, not just variants. They are languages in their own right. Trying to insert them into the fallback process just screws things up, because they need a "sideways" matching not just simple truncation fallback. If you want to do any fallback with extlang, it would be to fall back from zh-yue-<other stuff> to zh-<other stuff>. That means that in order to do reasonable fallback, you can't just use truncation fallback anyway. So I see the situation this way:

  1. The only reason for adding the complication of the extlang mechanism is to make truncation fallback work better.
  2. Truncation fallback with extlang doesn't work better.
  3. So there is no need to make encompassed languages be "secondary" languages by making them be "secondary" subtags.

The goals of extlang are good, to make matching work better, but in practice it just makes things worse. [Speaking to those familiar with C++, it feels a bit like the default assignment operator in C++. Nice in theory, but in practice it gums things up more than it fixes, since once you are beyond very simple (toy) classes, the default is almost always wrong -- but because it is supplied behind your back you don't realize it.]

So instead of adding the extlang mechanism to RFC 4646, what we really need to do is to point people to how to handle yue and other encompassed languages along with mo/ro, tl/fil, and other edge cases in a reasonable way, by augmenting matching.

Mark

On 7/15/07, Doug Ewell <dewell@roadrunner.com > wrote:
Mark Davis wrote:

> The main argument I've hear for extlang is behind-the-scenes-inertia.
> While we made provision in 4646 for possibly accepting them in the
> future, it was by no means a done-deal.

The main argument that has been offered is that it makes matching
easier.  Whether that argument was heard is a different question.

> The only reason I've heard advocated for them is that it makes
> matching easier. But in practice, we have simply not found that to be
> true. If it is indeed  worthwhile to add this mechanism to 4646, a
> good case needs to be made for it; and inertia isn't a good case.

Here is the argument restated.  It is based not on behind-the-scenes
inertia, but on backward compatibility, the exact same issue that caused
us to adopt Suppress-Script.

Existing Cantonese text has been tagged as "zh", the basic ISO
639-1-based tag, or as "zh-yue", the tag that was registered for this
purpose back in 1999.

The extlang mechanism would have established "yue" as an extlang under
"zh", so the proper tagging of Cantonese would continue to be "zh" (more
general) or "zh-yue" (more specific).  Matching engines would continue
to operate as they do now.

The proposed mechanism establishes "yue" as a primary language subtag,
so the proper tagging of Cantonese becomes "yue".  Matching engines must
be upgraded to RFC 4646bis in order to have any chance at finding a
match.  The much-beloved and much-catered-to RFC 3066 remove-from-right
"fallback" algorithm will NEVER find a match between "yue" and "zh",
regardless of whether script and/or region subtags are involved.

Put another way: Extlangs may not make matching easier, but *not* having
extlangs will make matching harder.

--
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




--
Mark ------=_Part_91054_20103429.1184699986433-- --===============1771091650== 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 --===============1771091650==-- From ltru-bounces@ietf.org Tue Jul 17 15:20:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsbK-0002rM-Pf; Tue, 17 Jul 2007 15:20:50 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IAsbJ-0002pn-94 for ltru-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 15:20:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsbI-0002mR-TJ for ltru@ietf.org; Tue, 17 Jul 2007 15:20:48 -0400 Received: from nz-out-0506.google.com ([64.233.162.231]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAsbH-0004gd-Fg for ltru@ietf.org; Tue, 17 Jul 2007 15:20:48 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1214115nzf for ; Tue, 17 Jul 2007 12:20:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ZEopkBZAamdCFgE6G15+9Mhb2/J0yV4GjrkjOIQHbWo1aPvRN7/4Kek2ouJorEgX3DwmMpn6NxqJGpGNEjSocxW+giElTCy2RxIejGhZGabt1dsxSgsYvQGE40FzK9SVZiGIymGmIxwOV0yetTyQIyVsBVIviZ2PNkBGOAC986M= 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=ZrIpGkiqUy6d3At7A35ygIRR7nT7mT6bT565SR1oZQ886Tq/beYBK7HA0DV82u+0n0sqK+nr2A4awdYOsuOHuhS8ydMmtpLGWkQWVnOF3KIecNU/wj/GiuXnV3TuzeKbbTSsIg7vOSmnl/mhe5+gWaFxRiGcUi8cbM/2SoLHiMY= Received: by 10.114.95.1 with SMTP id s1mr707319wab.1184700046165; Tue, 17 Jul 2007 12:20:46 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Tue, 17 Jul 2007 12:20:46 -0700 (PDT) Message-ID: <30b660a20707171220t4bd1555ax751599fb4d2a6779@mail.gmail.com> Date: Tue, 17 Jul 2007 12:20:46 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] examples of registration form... In-Reply-To: <469D1010.3000805@yahoo-inc.com> MIME-Version: 1.0 References: <469D1010.3000805@yahoo-inc.com> X-Google-Sender-Auth: 0ca19fadaf27bbd8 X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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="===============0150021113==" Errors-To: ltru-bounces@ietf.org --===============0150021113== Content-Type: multipart/alternative; boundary="----=_Part_91090_924482.1184700046131" ------=_Part_91090_924482.1184700046131 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline +1 On 7/17/07, Addison Phillips wrote: > > All, > > In editing today I noticed again that Section 3.3 (Maintenance of the > Registry) contains an example registration form. > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.html#maintreg > > This is annoying in part because the actual registration form is not > introduced until Section 3.5. Section 3.3 also repeats a number of > things that appear in Section 3.5. I propose to do the following: > > 1. Remove the example form from Section 3.3, along with the preceding > paragraph. Note that this information is already in Section 3.5. > > 2. Move the two paragraphs following the form to Section 3.5. > > 3. Move the three paragraphs now at the end of Section 3.3 (I moved them > there sometime during draft-07's gestation) to Section 3.4 (Stability), > since they deal with the stability of the grandfathered/redundant set. > > 4. Add two or three examples to a new document appendix of registration > forms. > > Thoughts? > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_91090_924482.1184700046131 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline +1

On 7/17/07, Addison Phillips <addison@yahoo-inc.com> wrote:
All,

In editing today I noticed again that Section 3.3 (Maintenance of the
Registry) contains an example registration form.

   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.html#maintreg

This is annoying in part because the actual registration form is not
introduced until Section 3.5. Section 3.3 also repeats a number of
things that appear in Section 3.5. I propose to do the following:

1. Remove the example form from Section 3.3, along with the preceding
paragraph. Note that this information is already in Section 3.5.

2. Move the two paragraphs following the form to Section 3.5.

3. Move the three paragraphs now at the end of Section 3.3 (I moved them
there sometime during draft-07's gestation) to Section 3.4 (Stability),
since they deal with the stability of the grandfathered/redundant set.

4. Add two or three examples to a new document appendix of registration
forms.

Thoughts?

Addison

--
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.


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



--
Mark ------=_Part_91090_924482.1184700046131-- --===============0150021113== 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 --===============0150021113==-- From ltru-bounces@ietf.org Tue Jul 17 15:21:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsbz-0003Dw-Bk; Tue, 17 Jul 2007 15:21:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IAsbx-0003DZ-Rm for ltru-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 15:21:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsbx-0003DR-I1 for ltru@ietf.org; Tue, 17 Jul 2007 15:21:29 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAsbw-0004pP-1R for ltru@ietf.org; Tue, 17 Jul 2007 15:21:29 -0400 Received: by wa-out-1112.google.com with SMTP id k17so2542867waf for ; Tue, 17 Jul 2007 12:21:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=V9q9W50y54JISG4yMDOR22KK5zJWek7Kemmb5XP8R8L9pToZUa1frBaj3r+jsjRNEGXzqoxxFFEYI5fXematUvicfxmtPpqgGrBWxZ4lxBaO+szxAH86ovAae5bGGGiUETLVHu43YntSV2iVxFwa+HCXX7mZzmjHtkx8zfijuu0= 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=RfVxIJxE9tyHpYuVa4YYV5Iinn2TwkoW4xJa+Z8A1DkUopSKNdrIrMdC9UFVh26S6hXLvGuPH0xcWC5NZGXxUkqCSmsSG7XKR2DBy3SVz6BT2GPn0U2StS9+Sx3aEdZ5EP3CnD7lHwZmeDguxk4u7Bp2KBCsyy6Ag1pWrhNTT4s= Received: by 10.114.148.1 with SMTP id v1mr730899wad.1184700086624; Tue, 17 Jul 2007 12:21:26 -0700 (PDT) Received: by 10.114.196.12 with HTTP; Tue, 17 Jul 2007 12:21:26 -0700 (PDT) Message-ID: <30b660a20707171221v556fdf42gb0533060440790a5@mail.gmail.com> Date: Tue, 17 Jul 2007 12:21:26 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Updated draft-4646bis... In-Reply-To: <469D0D41.8000202@yahoo-inc.com> MIME-Version: 1.0 References: <469CF74C.9070103@yahoo-inc.com> <30b660a20707171121h48c29bf4l761f108014d06ca4@mail.gmail.com> <469D0D41.8000202@yahoo-inc.com> X-Google-Sender-Auth: dadbebc18014d7eb X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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="===============0806296311==" Errors-To: ltru-bounces@ietf.org --===============0806296311== Content-Type: multipart/alternative; boundary="----=_Part_91110_13362917.1184700086578" ------=_Part_91110_13362917.1184700086578 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ok On 7/17/07, Addison Phillips wrote: > > NB> In inserting this text, I edited it for flow and formatting. I > eliminated some redundant (and, in my view, slightly hyperbolic) text. > The inserted text reads: > > -- > The 'mis' (Uncoded) primary language subtag identifies content whose > language is known but which does not currently have a corresponding > subtag. This subtag SHOULD NOT be used. Because the addition of other > codes in the future can render its application invalid, it is inherently > unstable and hence incompatible with the stability goals of BCP 47. It > is always preferable to use other subtags: either 'und' or (with prior > agreement) private use subtags. > -- > > I moved the definition to the first sentence so that this item is more > like the surrounding items. > > Addison > > Mark Davis wrote: > > I don't see the following in the text, although I believe there was > > rough consensus. You have something there, but the language is not > > nearly forceful enough). > > > > The ' mis' (Uncoded) primary language subtag SHOULD NOT be used. > > According to ISO 639, it is used to identify linguistic content whose > > language is known but which does not *currently* have a corresponding > > subtag. It is thus intrinsically unstable -- the addition of other codes > > in the future can render its application invalid at any point without > > any warning -- and hence incompatible with the stability goals of BCP > > 47. It is thus always preferable to use other subtags: either "und" or > > -- with prior agreement -- private use subtags. > > > > See: > > > > > > date > > Jun 16, 2007 8:29 AM > > > > subject > > Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: > "mis") > > > > > > > > Mark > > > > On 7/17/07, *Addison Phillips* > > wrote: > > > > All, > > > > I have just completed and posted my edits to draft-07. I have not > yet > > submitted them to the ID Editor... as Martin points out, the integer > > burning forge is currently on hiatus, pending IETF #69. > > > > However, the edits are all in place and can be used to further the > > discussion. Note that I have not incorporated the proposed text > related > > to Macrolanguage. However I have incorporated my proposed UTF-8 > changes. > > > > A diff from draft-06 can be accessed here: > > > > http://tinyurl.com/2o7t6m > > > > The documents posted are: > > > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.html > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.txt > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.xml > > > > Happy commenting. > > > > Addison > > > > -- > > Addison Phillips > > Globalization Architect -- Yahoo! Inc. > > Chair -- W3C Internationalization Core WG > > > > Internationalization is an architecture. > > It is not a feature. > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > -- > > Mark > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > -- Mark ------=_Part_91110_13362917.1184700086578 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline ok

On 7/17/07, Addison Phillips <addison@yahoo-inc.com> wrote:
NB> In inserting this text, I edited it for flow and formatting. I
eliminated some redundant (and, in my view, slightly hyperbolic) text.
The inserted text reads:

--
<t>The 'mis' (Uncoded) primary language subtag identifies content whose
language is known but which does not currently have a corresponding
subtag. This subtag SHOULD NOT be used. Because the addition of other
codes in the future can render its application invalid, it is inherently
unstable and hence incompatible with the stability goals of BCP 47. It
is always preferable to use other subtags: either 'und' or (with prior
agreement) private use subtags.</t>
--

I moved the definition to the first sentence so that this item is more
like the surrounding items.

Addison

Mark Davis wrote:
> I don't see the following in the text, although I believe there was
> rough consensus. You have something there, but the language is not
> nearly forceful enough).
>
> The ' mis' (Uncoded) primary language subtag SHOULD NOT be used.
> According to ISO 639, it is used to identify linguistic content whose
> language is known but which does not *currently* have a corresponding
> subtag. It is thus intrinsically unstable -- the addition of other codes
> in the future can render its application invalid at any point without
> any warning -- and hence incompatible with the stability goals of BCP
> 47. It is thus always preferable to use other subtags: either "und" or
> -- with prior agreement -- private use subtags.
>
> See:
>
>
>       date
>       Jun 16, 2007 8:29 AM
>
>       subject
>       Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis")
>
>
>
> Mark
>
> On 7/17/07, *Addison Phillips* < addison@yahoo-inc.com
> <mailto:addison@yahoo-inc.com>> wrote:
>
>     All,
>
>     I have just completed and posted my edits to draft-07. I have not yet
>     submitted them to the ID Editor... as Martin points out, the integer
>     burning forge is currently on hiatus, pending IETF #69.
>
>     However, the edits are all in place and can be used to further the
>     discussion. Note that I have not incorporated the proposed text related
>     to Macrolanguage. However I have incorporated my proposed UTF-8 changes.
>
>     A diff from draft-06 can be accessed here:
>
>        http://tinyurl.com/2o7t6m
>
>     The documents posted are:
>
>         http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.html
>        http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.txt
>        http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-07.xml
>
>     Happy commenting.
>
>     Addison
>
>     --
>     Addison Phillips
>     Globalization Architect -- Yahoo! Inc.
>     Chair -- W3C Internationalization Core WG
>
>     Internationalization is an architecture.
>     It is not a feature.
>
>
>     _______________________________________________
>     Ltru mailing list
>     Ltru@ietf.org <mailto:Ltru@ietf.org >
>     https://www1.ietf.org/mailman/listinfo/ltru
>
>
>
>
> --
> Mark

--
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.



--
Mark ------=_Part_91110_13362917.1184700086578-- --===============0806296311== 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 --===============0806296311==-- From ltru-bounces@ietf.org Tue Jul 17 15:34:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsoZ-0004UQ-63; Tue, 17 Jul 2007 15:34:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IAsoX-0004UL-Ug for ltru-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 15:34:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsoX-0004UD-L9 for ltru@ietf.org; Tue, 17 Jul 2007 15:34:29 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAsoV-0005CI-Rc for ltru@ietf.org; Tue, 17 Jul 2007 15:34:29 -0400 Received: from [10.72.73.49] (snvvpn1-10-72-73-c49.corp.yahoo.com [10.72.73.49]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l6HJYGDN022028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 12:34:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=r3tvpdO1O0zGPS/m8hVScQOYk+ZkfXKEXZW+dpb16Rej8odQlQdZPhtkagdjtiiK Message-ID: <469D19B8.2080306@yahoo-inc.com> Date: Tue, 17 Jul 2007 12:34:16 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Re: Macrolanguage and extlang References: <013b01c7c6a8$55cb4a20$6401a8c0@DGBP7M81> <20070715152301.GY9402@mercury.ccil.org> In-Reply-To: <20070715152301.GY9402@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 So far I've let Mark take this thread on, but now I have a few minutes to chime in. > >>> Addision and I have discussed the issue of extlang and Macrolanguages >>> and are proposing the following text replacing the use of extlang. >> I won't object to this proposed solution. > > I don't object to having a Macrolanguage header as such, and even to > making it mutable (and therefore informative). Good, although I note that it can't be (as) informative if we have extlangs. I mean, we could allow extlangs to lose their encompassed status, but not their Prefix. This is a problem we don't have to have if we don't have extlangs. > > I do most strenuously object to upsetting the extlang applecart. Extlangs > are a sensible and necessary shim between the 639-2-only world of 4646 > and the mixed 639-2/3 world of 4646bis, and I have seen no compelling > reasons why they should be discarded. We have been planning them for > years, and we should stick to our plan unless there is some hard reason > to change it. Up until now I've been pushing the extlang applecart (as it were), so Mark's message marks a departure for me. The problem is whether the shim is actually necessary. With extlangs we get the benefit of the subtag hierarchy being visible. Users are required to retag data to get full benefit from the new subtags, but they aren't *required* to retag their data. Neither are they required to retag their data if we just include all of the 639-3 codes as primary language subtags and forego extlangs. For most of the affected languages, extlangs are nothing but a hassle. Rather limited amounts of content are tagged with the macrolanguage, let alone with the enclosed sub language. Users can choose between primary language subtags on their own and need not use complex (and possibly not well-understood) subtag sequences. The various Hmongs, Quechuas, and Zapotecs fall into this category. The languages which are really affected are Arabic and Chinese. For Arabic, I think we could deprecate (or just frown at) the use of 'arb' (Standard Arabic) and let people choose regional Arabic dialects--or just use 'ar-*'. So we're left with Chinese, which is a huge sticky wicket. It's quite clear that there is a *lot* of content tagged with 'zh-*'. It's also clear that, for written content, we can maintain the "fiction" of Chinese and basically ignore regional languages/dialects for most tagging purposes. Users who really need the different Sinitic languages can tag them using the appropriate primary language subtag. The people who are hurt by this are those with non-written content, such as audio or video recordings, or similar kinds of applications (such as text-to-speech). For these sorts of applications, the users will have to retag their data. Either they use extlangs or they just use primary langauge subtags. It does mean that I might get a DVD with: