From ltru-bounces@ietf.org Sat Feb 03 19:32:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDVHo-0004XI-1u; Sat, 03 Feb 2007 19:31:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDVHn-0004X8-4w for ltru@ietf.org; Sat, 03 Feb 2007 19:31:15 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDVHj-0004uT-Sd for ltru@ietf.org; Sat, 03 Feb 2007 19:31:15 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070204003109.ERHG18698.mta9.adelphia.net@DGBP7M81> for ; Sat, 3 Feb 2007 19:31:09 -0500 Message-ID: <007501c747f3$c30db930$6801a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 3 Feb 2007 16:31:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Status of RFC 4645bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Since posting draft-ietf-ltru-4645bis-02, the only comments I've received about the draft or its proposed contents (other than the hex NCRs, which are an RFC 4646bis issue) were from Debbie, who mentioned some minor wording changes that I'm waiting for specifics on. Does this mean everyone loves the draft and feels it's about ready to go? The ISO 639-3 folks have been updating their data files in response to the issues I raised, and apparently the standard is ready to be published, possibly by the end of this month, so I'd like to prepare a draft-03 that would be ready for WG Last Call. Please send any comments. -- 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 Feb 08 09:52:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFAdQ-0002uh-T0; Thu, 08 Feb 2007 09:52:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFAdO-0002uV-7x for ltru@ietf.org; Thu, 08 Feb 2007 09:52:26 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFAdJ-0004fL-SF for ltru@ietf.org; Thu, 08 Feb 2007 09:52:26 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070208145219.QBLE5302.mta9.adelphia.net@DGBP7M81> for ; Thu, 8 Feb 2007 09:52:19 -0500 Message-ID: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 8 Feb 2007 06:52:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ltru] Progress X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org ISO is reporting that ISO 639-3 has been published [1] and the ISO 639-3 Web site has been edited [2] and files renamed to remove the "FDIS" qualifier throughout. This removes our last external obstacle to moving RFC 4646bis and 4645bis forward. Our goals were to submit these documents for IETF Last Call by the end of January, provided that ISO 639-3 had been published (the charter actually says "fully approved," which is surely implied by publication). As Mark might put it, it is now the 39th of January and we need to get moving if we are going to make the deadline. I have received no detailed comments on changes to be made in RFC 4645bis, and will be completely ready to go in a day or so with a draft-02, intended for WG LC, that uses the (apparently final) 639-3 download tables. However, I don't think I'm supposed to do this unless 4646bis is ready for WG LC as well (partly because of the lingering hex-NCRs question). Maybe there is some other reason we should be waiting and not taking action to move these documents forward, but I can't think of any. [1] http://www.iso.org/iso/en/CombinedQueryResult.CombinedQueryResult?queryString=639 [2] http://www.sil.org/iso639-3/ -- 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 Feb 08 09:56:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFAh8-0004H3-SW; Thu, 08 Feb 2007 09:56:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFAh8-0004Gr-85 for ltru@ietf.org; Thu, 08 Feb 2007 09:56:18 -0500 Received: from an-out-0708.google.com ([209.85.132.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFAh5-0005jx-Py for ltru@ietf.org; Thu, 08 Feb 2007 09:56:18 -0500 Received: by an-out-0708.google.com with SMTP id d30so533439and for ; Thu, 08 Feb 2007 06:56:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=fpY4r5DV27NpOi8PnHKeRw9HsT0cerYq8tR24QEyi0yY6LgEpU7vxkHakwh7cpYMFPzEZholxzNAiv6/3F6+za7/joApYd0FlqsYc+rS+B/IVEafLltpZVONU8ewupc0Z5Xa3MGdATwZ1brcURjnj/AMjQq+d1AO+jm2nxoXlSA= Received: by 10.100.163.12 with SMTP id l12mr10875978ane.1170946575525; Thu, 08 Feb 2007 06:56:15 -0800 (PST) Received: by 10.90.50.20 with HTTP; Thu, 8 Feb 2007 06:56:10 -0800 (PST) Message-ID: <30b660a20702080656j151881eeg307a933bce10e5cf@mail.gmail.com> Date: Thu, 8 Feb 2007 06:56:10 -0800 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Progress In-Reply-To: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> MIME-Version: 1.0 References: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> X-Google-Sender-Auth: 1dff8a8883971b94 X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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="===============1147850420==" Errors-To: ltru-bounces@ietf.org --===============1147850420== Content-Type: multipart/alternative; boundary="----=_Part_15060_1936563.1170946570486" ------=_Part_15060_1936563.1170946570486 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > 4646bis I can. Not all of my requests for changes have been considered (they may of course be rejected, but that needs to be explicit). I will put together a list and send to this group. Mark On 2/8/07, Doug Ewell wrote: > > ISO is reporting that ISO 639-3 has been published [1] and the ISO 639-3 > Web site has been edited [2] and files renamed to remove the "FDIS" > qualifier throughout. > > This removes our last external obstacle to moving RFC 4646bis and > 4645bis forward. Our goals were to submit these documents for IETF Last > Call by the end of January, provided that ISO 639-3 had been published > (the charter actually says "fully approved," which is surely implied by > publication). As Mark might put it, it is now the 39th of January and > we need to get moving if we are going to make the deadline. > > I have received no detailed comments on changes to be made in RFC > 4645bis, and will be completely ready to go in a day or so with a > draft-02, intended for WG LC, that uses the (apparently final) 639-3 > download tables. However, I don't think I'm supposed to do this unless > 4646bis is ready for WG LC as well (partly because of the lingering > hex-NCRs question). Maybe there is some other reason we should be > waiting and not taking action to move these documents forward, but I > can't think of any. > > [1] > > http://www.iso.org/iso/en/CombinedQueryResult.CombinedQueryResult?queryString=639 > [2] http://www.sil.org/iso639-3/ > > -- > 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_15060_1936563.1170946570486 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline > 4646bis

I can. Not all of my requests for changes have been considered (they may of course be rejected, but that needs to be explicit). I will put together a list and send to this group.

Mark

On 2/8/07, Doug Ewell <dewell@adelphia.net> wrote:
ISO is reporting that ISO 639-3 has been published [1] and the ISO 639-3
Web site has been edited [2] and files renamed to remove the "FDIS"
qualifier throughout.

This removes our last external obstacle to moving RFC 4646bis and
4645bis forward.  Our goals were to submit these documents for IETF Last
Call by the end of January, provided that ISO 639-3 had been published
(the charter actually says "fully approved," which is surely implied by
publication).  As Mark might put it, it is now the 39th of January and
we need to get moving if we are going to make the deadline.

I have received no detailed comments on changes to be made in RFC
4645bis, and will be completely ready to go in a day or so with a
draft-02, intended for WG LC, that uses the (apparently final) 639-3
download tables.  However, I don't think I'm supposed to do this unless
4646bis is ready for WG LC as well (partly because of the lingering
hex-NCRs question).  Maybe there is some other reason we should be
waiting and not taking action to move these documents forward, but I
can't think of any.

[1]
http://www.iso.org/iso/en/CombinedQueryResult.CombinedQueryResult?queryString=639
[2] http://www.sil.org/iso639-3/

--
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_15060_1936563.1170946570486-- --===============1147850420== 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 --===============1147850420==-- From ltru-bounces@ietf.org Thu Feb 08 18:01:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFIH3-00059v-76; Thu, 08 Feb 2007 18:01:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFIGz-00059J-Hw; Thu, 08 Feb 2007 18:01:49 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HFIGx-0004VB-9F; Thu, 08 Feb 2007 18:01:49 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 370AC17617; Thu, 8 Feb 2007 23:01:17 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HFIGS-0005BY-S8; Thu, 08 Feb 2007 18:01:16 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 08 Feb 2007 18:01:16 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf-languages@iana.org, ltru@ietf.org Subject: [Ltru] Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) to Proposed Standard X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Language Tag MIB ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-mcwalter-langtag-mib-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15469&rfc_flag=0 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Feb 08 20:51:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFKuh-000679-Ri; Thu, 08 Feb 2007 20:50:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFKuf-00066v-JE for ltru@ietf.org; Thu, 08 Feb 2007 20:50:57 -0500 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFKub-0006Ox-S5 for ltru@ietf.org; Thu, 08 Feb 2007 20:50:57 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 8 Feb 2007 17:50:53 -0800 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; Thu, 8 Feb 2007 17:50:51 -0800 From: Peter Constable To: Mark Davis , Doug Ewell Date: Thu, 8 Feb 2007 17:50:49 -0800 Subject: RE: [Ltru] Progress Thread-Topic: [Ltru] Progress Thread-Index: AcdLkUsRAU2wxiKiT3yFPJPI6c7bXwAWnWeg Message-ID: References: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> <30b660a20702080656j151881eeg307a933bce10e5cf@mail.gmail.com> In-Reply-To: <30b660a20702080656j151881eeg307a933bce10e5cf@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a 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="===============0127669712==" Errors-To: ltru-bounces@ietf.org --===============0127669712== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB835795548891148ENAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB835795548891148ENAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I can think of another reason: ISO Central Secretariat completed publicatio= n faster than we expected: we thought they'd take a few weeks but they post= ed it the very next day. We still have some details in the code table wrt w= hat to do with certain 639-2 entries that we're sorting out. Now we have an= unfortunate quandary: because of the ISO announcement, the downloadable da= ta files can be considered published even though there may be a few things = in there that are not ideal meaning we'd be stuck with them. I wish we coul= d clear those up before they got incorporated into a 4645bis draft. Peter ________________________________ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Thursday, February 08, 2007 6:56 AM To: Doug Ewell Cc: LTRU Working Group Subject: Re: [Ltru] Progress > 4646bis I can. Not all of my requests for changes have been considered (they may of= course be rejected, but that needs to be explicit). I will put together a = list and send to this group. Mark On 2/8/07, Doug Ewell > wro= te: ISO is reporting that ISO 639-3 has been published [1] and the ISO 639-3 Web site has been edited [2] and files renamed to remove the "FDIS" qualifier throughout. This removes our last external obstacle to moving RFC 4646bis and 4645bis forward. Our goals were to submit these documents for IETF Last Call by the end of January, provided that ISO 639-3 had been published (the charter actually says "fully approved," which is surely implied by publication). As Mark might put it, it is now the 39th of January and we need to get moving if we are going to make the deadline. I have received no detailed comments on changes to be made in RFC 4645bis, and will be completely ready to go in a day or so with a draft-02, intended for WG LC, that uses the (apparently final) 639-3 download tables. However, I don't think I'm supposed to do this unless 4646bis is ready for WG LC as well (partly because of the lingering hex-NCRs question). Maybe there is some other reason we should be waiting and not taking action to move these documents forward, but I can't think of any. [1] http://www.iso.org/iso/en/CombinedQueryResult.CombinedQueryResult?queryStri= ng=3D639 [2] http://www.sil.org/iso639-3/ -- 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 --_000_DDB6DE6E9D27DD478AE6D1BBBB835795548891148ENAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I can think of another reason: ISO Central Secretariat completed publication faster than we expected: we thoug= ht they’d take a few weeks but they posted it the very next day. We stil= l have some details in the code table wrt what to= do with certain 639-2 entries that we’re sorting out. Now we have an unfortunate quandary: because of the ISO announcement, the downloadable dat= a files can be considered published even though there may be a few things in there that are not ideal meaning we’d be stuck with them. I wish we c= ould clear those up before they got incorporated into a 4645bis draft.

 

Peter

 

From: Mark Dav= is [mailto:mark.davis@icu-project.org]
Sent: Thursday, February 08,= 2007 6:56 AM
To: Doug Ewell
Cc: LTRU Working Group
Subject: Re: [Ltru] Progress=

 

> 4646bis

I can. Not all of my requests for changes have been considered (they may of course be rejected, but that needs to be explicit). I will put together a l= ist and send to this group.

Mark

On 2/8/07, D= oug Ewell <dewell@adelphia= .net> wrote:

ISO is reporting that ISO 639-3 has been published [1] and the ISO 639-3
Web site has been edited [2] and files renamed to remove the "FDIS&quo= t;
qualifier throughout.

This removes our last external obstacle to moving RFC 4646bis and
4645bis forward.  Our goals were to submit these documents for IE= TF Last
Call by the end of January, provided that ISO 639-3 had been published
(the charter actually says "fully approved," which is surely impl= ied by
publication).  As Mark might put it, it is now the 39th of Januar= y and
we need to get moving if we are going to make the deadline.

I have received no detailed comments on changes to be made in RFC
4645bis, and will be completely ready to go in a day or so with a
draft-02, intended for WG LC, that uses the (apparently final) 639-3
download tables.  However, I don't think I'm supposed to do this unless
4646bis is ready for WG LC as well (partly because of the lingering
hex-NCRs question).  Maybe there is some other reason we should b= e
waiting and not taking action to move these documents forward, but I
can't think of any.

[1]
http://www.iso.org/iso/en/CombinedQueryResult.CombinedQue= ryResult?queryString=3D639
[2] http://www.sil.org/iso639-3/

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~d= ewell/
http://www= 1.ietf.org/html.charters/ltru-charter.html
http:/= /www.alvestrand.no/mailman/listinfo/ietf-languages


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




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB835795548891148ENAEXMSGC117re_-- --===============0127669712== 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 --===============0127669712==-- From ltru-bounces@ietf.org Fri Feb 09 02:08:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFPrJ-0005mb-3h; Fri, 09 Feb 2007 02:07:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFPrH-0005mC-R6 for ltru@ietf.org; Fri, 09 Feb 2007 02:07:47 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFPrG-0007rr-IF for ltru@ietf.org; Fri, 09 Feb 2007 02:07:47 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070209070743.IXSA20866.mta9.adelphia.net@DGBP7M81>; Fri, 9 Feb 2007 02:07:43 -0500 Message-ID: <000e01c74c18$fe52e500$6801a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> <30b660a20702080656j151881eeg307a933bce10e5cf@mail.gmail.com> Subject: Re: [Ltru] Progress Date: Thu, 8 Feb 2007 23:07:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > I can think of another reason: ISO Central Secretariat completed > publication faster than we expected: we thought they’d take a few > weeks but they posted it the very next day. We still have some details > in the code table wrt what to do with certain 639-2 entries that we’re > sorting out. Now we have an unfortunate quandary: because of the ISO > announcement, the downloadable data files can be considered published > even though there may be a few things in there that are not ideal > meaning we’d be stuck with them. I wish we could clear those up before > they got incorporated into a 4645bis draft. I can delay the draft as long as necessary so you can get the changes in. It looks like that's going to happen anyway. -- 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 Feb 09 10:06:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXJb-0002Wo-HJ; Fri, 09 Feb 2007 10:05:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXJZ-0002Wb-Cj for ltru@lists.ietf.org; Fri, 09 Feb 2007 10:05:29 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFXJX-00070V-2x for ltru@lists.ietf.org; Fri, 09 Feb 2007 10:05:29 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HFXJO-0002Ru-HP for ltru@lists.ietf.org; Fri, 09 Feb 2007 16:05:18 +0100 Received: from d254119.dialin.hansenet.de ([80.171.254.119]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Feb 2007 16:05:18 +0100 Received: from nobody by d254119.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Feb 2007 16:05:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 09 Feb 2007 16:04:10 +0100 Organization: Lines: 19 Message-ID: <45CC8D6A.7E7E@xyzzy.claranet.de> References: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> <30b660a20702080656j151881eeg307a933bce10e5cf@mail.gmail.com> <000e01c74c18$fe52e500$6801a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254119.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: Progress X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > I can delay the draft as long as necessary so you can get the changes > in. It looks like that's going to happen anyway. If you or Peter like to get a plausibility check based on my registry to XML to validator.w3 approach you could publish the actual state anyway (as I-D or proto-registry file). Of course you can also do that directly with the gawk script. For 4646bis I think we're still far from ready, there were tons of editorial details (including stuff about the review list operation). But that's not directly related to your part unless we find that the only way to get the missing Suppress-Scripts right for the pre-639-3 languages is to do it "here" (in 4645bis). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Feb 10 12:52:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFwNa-0005UC-2h; Sat, 10 Feb 2007 12:51:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFwNW-0005Tt-U1; Sat, 10 Feb 2007 12:51:14 -0500 Received: from mta15.adelphia.net ([68.168.78.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFwNV-0000Se-K9; Sat, 10 Feb 2007 12:51:14 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070210173915.WQPP22571.mta15.adelphia.net@DGBP7M81>; Sat, 10 Feb 2007 12:39:15 -0500 Message-ID: <005301c74d3c$0bb00510$6801a8c0@DGBP7M81> From: "Doug Ewell" To: References: <20070210110002.CA2702596E8@eikenes.alvestrand.no> Date: Sat, 10 Feb 2007 09:51:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ietf-languages@iana.org, LTRU Working Group Subject: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) 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 The IESG wrote: > The IESG has received a request from an individual submitter to > consider the following document: > > - 'Language Tag MIB ' > as a Proposed Standard This document defines a profile of RFC 4646 language tags for use in a particular application, by restricting the tags to lowercase and no more than 60 characters in length. There is a recommended casing convention described in RFC 4646, section 2.1 (e.g. "hmn-Latn-LA"), but tags are not intended to be case-sensitive, and applications such as this one may choose a different convention if it suits them. Section 4.3 of RFC 4646 discusses tag length limitations and suggests a minimum length limit of 42 characters. The proposed limit of 60 characters in the I-D is greater than that minimum, and much greater than the likely maximum length of any non-private-use tag, and should pose no problem. Since tags of 1 character are never well-formed, I suggest that the definition: SYNTAX OCTET STRING (SIZE (0..60)) be amended to exclude the 1-character case. I assume that a zero-length tag, while also not defined in RFC 4646, was included in the I-D to allow the special case of "no tag." -- 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 Feb 10 13:15:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFwlH-0005xZ-Vp; Sat, 10 Feb 2007 13:15:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFwlG-0005tW-6J; Sat, 10 Feb 2007 13:15:46 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFwlE-0006Cp-VT; Sat, 10 Feb 2007 13:15:46 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HFwl5-0006J3-Tr; Sat, 10 Feb 2007 13:15:36 -0500 Date: Sat, 10 Feb 2007 13:15:35 -0500 To: Doug Ewell Message-ID: <20070210181535.GN30294@mercury.ccil.org> References: <20070210110002.CA2702596E8@eikenes.alvestrand.no> <005301c74d3c$0bb00510$6801a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005301c74d3c$0bb00510$6801a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf-languages@iana.org, LTRU Working Group , ietf@ietf.org Subject: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) 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 Doug Ewell scripsit: > Since tags of 1 character are never well-formed, I suggest that the > definition: > > SYNTAX OCTET STRING (SIZE (0..60)) > > be amended to exclude the 1-character case. I assume that a zero-length > tag, while also not defined in RFC 4646, was included in the I-D to > allow the special case of "no tag." AFAIK, ASN.1 does not allow sizes like (0, 2..60). I wouldn't even bother with this change. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Rather than making ill-conceived suggestions for improvement based on uninformed guesses about established conventions in a field of study with which familiarity is limited, it is sometimes better to stick to merely observing the usage and listening to the explanations offered, inserting only questions as needed to fill in gaps in understanding. --Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Feb 10 16:03:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFzNk-00043h-Dz; Sat, 10 Feb 2007 16:03:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFzNi-0003zq-U7 for ltru@ietf.org; Sat, 10 Feb 2007 16:03:38 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFzNh-0006H1-LG for ltru@ietf.org; Sat, 10 Feb 2007 16:03:38 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070210210330.XXMA28666.mta9.adelphia.net@DGBP7M81>; Sat, 10 Feb 2007 16:03:30 -0500 Message-ID: <007c01c74d56$ea129100$6801a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 10 Feb 2007 13:03:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Frank Ellermann Subject: [Ltru] Re: Progress X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > If you or Peter like to get a plausibility check based on my registry > to XML to validator.w3 approach you could publish the actual state > anyway (as I-D or proto-registry file). Of course you can also do > that directly with the gawk script. If anyone would like to try this: http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-01.txt http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.txt http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.html -- 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 Feb 10 16:16:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFzZt-0002rI-Ta; Sat, 10 Feb 2007 16:16:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFzZr-0002r6-Td; Sat, 10 Feb 2007 16:16:11 -0500 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFzZp-0000cV-GB; Sat, 10 Feb 2007 16:16:11 -0500 Received: from localhost (localhost [127.0.0.1]) by mail2.sharplabs.com (Postfix) with ESMTP id B61EB1E134A; Sat, 10 Feb 2007 13:16:06 -0800 (PST) Received: from mail2.sharplabs.com ([127.0.0.1]) by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06021-05-2; Sat, 10 Feb 2007 13:16:04 -0800 (PST) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 57B291E1336; Sat, 10 Feb 2007 13:16:04 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1T0Q6JNB>; Sat, 10 Feb 2007 13:16:04 -0800 Message-ID: <789E617C880666438EDEE30C2A3E8D100105A5E6@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'John Cowan' , Doug Ewell Subject: RE: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Ta g MIB) to Proposed Standard Date: Sat, 10 Feb 2007 13:15:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: amavisd-new at sharplabs.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ietf-languages@iana.org, LTRU Working Group , ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, Right - ASN.1 doesn't allow discontinuous integer ranges. The DESCRIPTION clause of this textual convention could disallow the length of '1', but it's not important to do, I think. With respect to max length of 60, the public MIBs that I'm aware of often use 63 octets and the rest use a longer max length (except for the admittedly flawed legacy objects in Printer MIB v2, RFC 3805 - I tried to fix them before we published RFC 3805, but got shot down by my co-editors). Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: John Cowan [mailto:cowan@ccil.org] Sent: Saturday, February 10, 2007 1:16 PM To: Doug Ewell Cc: ietf-languages@iana.org; LTRU Working Group; ietf@ietf.org Subject: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) to Proposed Standard Doug Ewell scripsit: > Since tags of 1 character are never well-formed, I suggest that the > definition: > > SYNTAX OCTET STRING (SIZE (0..60)) > > be amended to exclude the 1-character case. I assume that a zero-length > tag, while also not defined in RFC 4646, was included in the I-D to > allow the special case of "no tag." AFAIK, ASN.1 does not allow sizes like (0, 2..60). I wouldn't even bother with this change. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Rather than making ill-conceived suggestions for improvement based on uninformed guesses about established conventions in a field of study with which familiarity is limited, it is sometimes better to stick to merely observing the usage and listening to the explanations offered, inserting only questions as needed to fill in gaps in understanding. --Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.17.33/678 - Release Date: 2/9/2007 4:06 PM _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Feb 11 12:45:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGIlT-0003Wa-M7; Sun, 11 Feb 2007 12:45:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGIlS-0003WC-H7 for ltru@lists.ietf.org; Sun, 11 Feb 2007 12:45:26 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGIlR-0004QU-5K for ltru@lists.ietf.org; Sun, 11 Feb 2007 12:45:26 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HGIlP-0004DF-Cl for ltru@lists.ietf.org; Sun, 11 Feb 2007 18:45:23 +0100 Received: from du-001-047.access.de.clara.net ([212.82.227.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Feb 2007 18:45:23 +0100 Received: from nobody by du-001-047.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Feb 2007 18:45:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 11 Feb 2007 18:42:34 +0100 Organization: Lines: 12 Message-ID: <45CF558A.2415@xyzzy.claranet.de> References: <007c01c74d56$ea129100$6801a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-047.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Progress X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > If anyone would like to try this: > http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-01.txt Hi Doug, I'm sorry for being unclear, of course I did that already with your 4645bis-01, compare http://purl.net/xyzzy/home/ltru IIRC you and/or Peter mentioned further modifications obsoleting -01. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Feb 12 03:12:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGWHt-0001so-Vb; Mon, 12 Feb 2007 03:11:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGWHt-0001sE-2c for ltru@ietf.org; Mon, 12 Feb 2007 03:11:49 -0500 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGWHr-0007h4-OO for ltru@ietf.org; Mon, 12 Feb 2007 03:11:49 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070212081144.MGUI14346.mta13.adelphia.net@DGBP7M81> for ; Mon, 12 Feb 2007 03:11:44 -0500 Message-ID: <004101c74e7d$6f0fbf50$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 12 Feb 2007 00:11:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: Progress X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > IIRC you and/or Peter mentioned further modifications obsoleting > [draft-ietf-ltru-4645bis]-01. There have been minor changes to the ISO 639-3 database (plus I guess some I haven't seen yet), that will be reflected in a draft-02. Additionally, two script subtags have been added to the existing Registry, and of course those have to be included in 4645bis as well. I'm not expecting any big structural changes that would affect convertibility to and from XML, but of course you never know. -- 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 Feb 12 03:49:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGWs3-0005j0-8X; Mon, 12 Feb 2007 03:49:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGWs1-0005im-Un for ltru@ietf.org; Mon, 12 Feb 2007 03:49:09 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGWry-0008EZ-KS for ltru@ietf.org; Mon, 12 Feb 2007 03:49:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 1E36E26C1E4; Mon, 12 Feb 2007 09:48:47 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 473BC26C158; Mon, 12 Feb 2007 09:48:44 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 3A89E58E9F0; Mon, 12 Feb 2007 09:48:44 +0100 (CET) Date: Mon, 12 Feb 2007 09:48:44 +0100 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20070212084844.GA14221@nic.fr> References: <007c01c74d56$ea129100$6801a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007c01c74d56$ea129100$6801a8c0@DGBP7M81> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: LTRU Working Group Subject: [Ltru] Re: Progress X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Feb 10, 2007 at 01:03:28PM -0800, Doug Ewell wrote a message of 24 lines which said: > http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-01.txt > http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.txt > http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.html Is there a "clean", a "bare" version of the registry, without RFC headers and footers so I can give it to my checking program? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Feb 12 09:08:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGbqu-00005q-1o; Mon, 12 Feb 2007 09:08:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGbqs-00005k-Kj for ltru@ietf.org; Mon, 12 Feb 2007 09:08:18 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGbqr-0002fQ-CW for ltru@ietf.org; Mon, 12 Feb 2007 09:08:18 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070212140812.UFJ28666.mta9.adelphia.net@DGBP7M81>; Mon, 12 Feb 2007 09:08:12 -0500 Message-ID: <006b01c74eaf$3acf3590$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <007c01c74d56$ea129100$6801a8c0@DGBP7M81> <20070212084844.GA14221@nic.fr> Date: Mon, 12 Feb 2007 06:08:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ltru] Re: Progress X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > Is there a "clean", a "bare" version of the registry, without RFC > headers and footers so I can give it to my checking program? There is now: http://users.adelphia.net/~dewell/lstreg-4645bis-01.txt -- 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 Feb 12 23:53:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGpfN-00061B-3v; Mon, 12 Feb 2007 23:53:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGpfL-000615-Nw for ltru@ietf.org; Mon, 12 Feb 2007 23:53:19 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGpfI-0004KR-PU for ltru@ietf.org; Mon, 12 Feb 2007 23:53:19 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l1D4r2jo022797 for ; Tue, 13 Feb 2007 13:53:02 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 6f4f_157bc174_bb1e_11db_9e9b_0014221fa3c9; Tue, 13 Feb 2007 13:53:02 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36610) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 13 Feb 2007 13:52:06 +0900 Message-Id: <6.0.0.20.2.20070209154630.06f74560@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 09 Feb 2007 15:48:42 +0900 To: Peter Constable , Mark Davis , Doug Ewell From: Martin Duerst Subject: RE: [Ltru] Progress In-Reply-To: References: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> <30b660a20702080656j151881eeg307a933bce10e5cf@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Hello Peter, What timeline do you expect for this cleanup work? What is the chance that it can actually be done (as opposed to being frozen because publication is already done)? Regards, Martin. At 10:50 07/02/09, Peter Constable wrote: >Content-Language: en-US >Content-Type: multipart/alternative;boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB835795548891148ENAEXMSGC117re_" > >I can think of another reason: ISO Central Secretariat completed publication faster than we expected: we thought they$BCE(B take a few weeks but they posted it the very next day. We still have some details in the code table wrt what to do with certain 639-2 entries that we$BCS(Be sorting out. Now we have an unfortunate quandary: because of the ISO announcement, the downloadable data files can be considered published even though there may be a few things in there that are not ideal meaning we$BCE(B be stuck with them. I wish we could clear those up before they got incorporated into a 4645bis draft. > >Peter > > >---------- >From: Mark Davis [mailto:mark.davis@icu-project.org] >Sent: Thursday, February 08, 2007 6:56 AM >To: Doug Ewell >Cc: LTRU Working Group >Subject: Re: [Ltru] Progress > >> 4646bis > >I can. Not all of my requests for changes have been considered (they may of course be rejected, but that needs to be explicit). I will put together a list and send to this group. > >Mark >On 2/8/07, Doug Ewell <dewell@adelphia.net> wrote: >ISO is reporting that ISO 639-3 has been published [1] and the ISO 639-3 >Web site has been edited [2] and files renamed to remove the "FDIS" >qualifier throughout. > >This removes our last external obstacle to moving RFC 4646bis and >4645bis forward. Our goals were to submit these documents for IETF Last >Call by the end of January, provided that ISO 639-3 had been published >(the charter actually says "fully approved," which is surely implied by >publication). As Mark might put it, it is now the 39th of January and >we need to get moving if we are going to make the deadline. > >I have received no detailed comments on changes to be made in RFC >4645bis, and will be completely ready to go in a day or so with a >draft-02, intended for WG LC, that uses the (apparently final) 639-3 >download tables. However, I don't think I'm supposed to do this unless >4646bis is ready for WG LC as well (partly because of the lingering >hex-NCRs question). Maybe there is some other reason we should be >waiting and not taking action to move these documents forward, but I >can't think of any. > >[1] >http://www.iso.org/iso/en/CombinedQueryResult.CombinedQueryResult?queryString=639 >[2] http://www.sil.org/iso639-3/ > >-- >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 >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 13 05:05:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGuWn-0004yC-4e; Tue, 13 Feb 2007 05:04:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGuWl-0004y4-B4 for ltru@ietf.org; Tue, 13 Feb 2007 05:04:47 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGuWk-0006VF-2A for ltru@ietf.org; Tue, 13 Feb 2007 05:04:47 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 7909626C173; Tue, 13 Feb 2007 11:04:26 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id AB4B326C1B4; Tue, 13 Feb 2007 11:04:25 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id A882658E9F0; Tue, 13 Feb 2007 11:04:25 +0100 (CET) Date: Tue, 13 Feb 2007 11:04:25 +0100 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20070213100425.GA8824@nic.fr> References: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: LTRU Working Group Subject: [Ltru] Re: Progress X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, Feb 08, 2007 at 06:52:18AM -0800, Doug Ewell wrote a message of 35 lines which said: > I have received no detailed comments on changes to be made in RFC > 4645bis, and will be completely ready to go in a day or so with a > draft-02, intended for WG LC, that uses the (apparently final) 639-3 > download tables. I just tested 4645bis with my registry checking program and I (it) found no problem. The only thing that puzzles me is the: Added: 2008-01-01 for all the ISO 639-3 languages. I assume it should be replaced by the actual date of publication of 639-3? For the fun, I loaded it in a database: lsr2=> SELECT count(*) FROM Languages; count ------- 7186 (1 row) lsr2=> SELECT count(*) FROM Languages WHERE added > now(); count ------- 6697 (1 row) lsr2=> SELECT count(*) FROM Languages WHERE added <= now(); count ------- 489 (1 row) lsr2=> SELECT count(*) FROM Extlangs; count ------- 480 (1 row) lsr2=> SELECT count(*) FROM Variants; count ------- 12 (1 row) Congratulations for the huge increase in size :-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 13 09:16:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGySL-0007FA-Pt; Tue, 13 Feb 2007 09:16:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGySK-0007F5-L7 for ltru@ietf.org; Tue, 13 Feb 2007 09:16:28 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGySI-0001I5-By for ltru@ietf.org; Tue, 13 Feb 2007 09:16:28 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070213141621.FJLE22452.mta10.adelphia.net@DGBP7M81>; Tue, 13 Feb 2007 09:16:21 -0500 Message-ID: <003801c74f79$88bc56f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> <20070213100425.GA8824@nic.fr> Date: Tue, 13 Feb 2007 06:16:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Ltru] Re: Progress X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > The only thing that puzzles me is the: > > Added: 2008-01-01 > > for all the ISO 639-3 languages. I assume it should be replaced by the > actual date of publication of 639-3? >From Section 2.1, "Starting Point": "The value of the File-Date field and of the Added date for each new subtag record are set to a date near the date of IESG approval of this memo. [RFC EDITOR NOTE: these dates would be updated during AUTH48.]" I've found that using a "real" date as a filler in this situation gets confusing. We are adding 7000 entries to a living Registry that is simultaneously undergoing its own changes, e.g. adding Meitei Mayak and Moon. Using an artificial date like 2008-01-01 clearly identifies the changes that are part of the bulk update. Ideally this date will be changed to the exact date of approval of the RFC. Last time around, the date of the final draft (2005-10-16) ended up enshrined as the "Added" date for everything in the Registry even though the RFC wasn't published until 11 months later. -- 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 l _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 13 09:46:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGyvD-0007E9-Pl; Tue, 13 Feb 2007 09:46:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGyvC-0007DJ-Qm for ltru@ietf.org; Tue, 13 Feb 2007 09:46:18 -0500 Received: from mail06.svc.cra.dublin.eircom.net ([159.134.118.22]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HGyuX-0002TG-Jt for ltru@ietf.org; Tue, 13 Feb 2007 09:45:38 -0500 Received: (qmail 49366 messnum 2906620 invoked from network[194.125.205.32/ts07-032.dublin.indigo.ie]); 13 Feb 2007 14:45:36 -0000 Received: from ts07-032.dublin.indigo.ie (HELO ?194.125.205.32?) (194.125.205.32) by mail06.svc.cra.dublin.eircom.net (qp 49366) with SMTP; 13 Feb 2007 14:45:36 -0000 In-Reply-To: <003801c74f79$88bc56f0$6401a8c0@DGBP7M81> References: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> <20070213100425.GA8824@nic.fr> <003801c74f79$88bc56f0$6401a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: Progress Date: Tue, 13 Feb 2007 14:48:10 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Personally, I feel that adding an artificial date only worsens the =20 confusion of genuine and other errors. As an Archivist, I felt =20 comfortable enough adding "g.d." (abbreviation in Irish for =20 "undated") to entries _sans- known date of publication. I think =20 following that principle/convention (which is accepted =20 internationally), would help. mg On 13 Feb 2007, at 14:16, scr=EDobh Doug Ewell: > ... I've found that using a "real" date as a filler in this =20 > situation gets confusing. We are adding 7000 entries to a living =20 > Registry that is simultaneously undergoing its own changes, e.g. =20 > adding Meitei Mayak and Moon. Using an artificial date like =20 > 2008-01-01 clearly identifies the changes that are part of the bulk =20= > update. Ideally this date will be changed to the exact date of =20 > approval of the RFC. Last time around, the date of the final draft =20= > (2005-10-16) ended up enshrined as the "Added" date for everything =20 > in the Registry even though the RFC wasn't published until 11 =20 > months later. - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 13 13:24:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2Jp-0006XO-PO; Tue, 13 Feb 2007 13:23:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2Jo-0006Wj-DR for ltru@ietf.org; Tue, 13 Feb 2007 13:23:56 -0500 Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH2Jn-0008E5-1H for ltru@ietf.org; Tue, 13 Feb 2007 13:23:56 -0500 Received: by wr-out-0506.google.com with SMTP id 55so2524502wri for ; Tue, 13 Feb 2007 10:23:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=AMnS7oFclTrIN0MQb5pp/TjyaptoiGvRyUIyvr/vzARxlTKwOWw3lHkhw2zRnhkVF6QUsZeCeuTQToA0OlDWEWn/CEobCwKKAX2RRXSGnh8I27hFOHCMlP+hsEw8jE/xkx9Y0ZpbvdYqzrKQwPHnr1HQS+h1eDx00QptiGLdXJs= Received: by 10.90.73.3 with SMTP id v3mr19642803aga.1171391034594; Tue, 13 Feb 2007 10:23:54 -0800 (PST) Received: by 10.90.50.20 with HTTP; Tue, 13 Feb 2007 10:23:54 -0800 (PST) Message-ID: <30b660a20702131023k53f09d76r1e37848af4853f1@mail.gmail.com> Date: Tue, 13 Feb 2007 10:23:54 -0800 From: "Mark Davis" To: "Doug Ewell" In-Reply-To: <004101c74f81$345acd50$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <20070213110003.032CE25970A@eikenes.alvestrand.no> <004101c74f81$345acd50$6401a8c0@DGBP7M81> X-Google-Sender-Auth: b7147350546a4d2e X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ietf-languages@iana.org, ltru@ietf.org Subject: [Ltru] Re: Macrolanguages, countries & orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0430082526==" Errors-To: ltru-bounces@ietf.org --===============0430082526== Content-Type: multipart/alternative; boundary="----=_Part_8517_30069797.1171391034548" ------=_Part_8517_30069797.1171391034548 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > I wonder if there is, or is going to be, a public forum to discuss ISO > 639-3 and its structure and policies. This list really isn't it; we > take what the external standards give us, and synthesize and arrange. > We don't directly influence what the external standards do, though there > are list members who can do so indirectly. That would be very useful. We are very dependent on the interpretation of the codes. In particular, there is a key item that we need a response for, and that is the temporal scope of ISO language codes. For example, we have french broken up into fr, frm, and fro, plus various creoles. So tagging old French data with fr is incorrect, and requesting a variant subtag to apply to fr to indicate French of say (1100-1200) is out of scope and will be legitimately rejected. For most other languages, on the other hand, we do not have that granularity. So that means what a document that is tagged with cs (Czech) represents is completely unspecified. We do not know what the !#$@ to do with a request. We are faced with an unknown situation which the ISO committee doesn't respond to. Assume that old Czech is as different from modern as fro is from fr. There are the following two alternatives: 1. The subtag 'cs' means any Czech, modern or old, and therefore 1. cs can legitimately be used to tag a document with old Czech. 2. a request for a variant-subtag applying to cs indicating old Czech is perfectly reasonable, and SHOULD be granted. 3. ISO can only add another subtag that means old Czech if cs is treated as a metalanguage, since otherwise that would invalidate old subtags. 2. The subtag 'cs mean only modern Czech, and therefore 1. cs cannot be correctly used to tag a document with old Czech, so the only recourse is to use a private use code or 'und'. 2. a request for a variant-subtag applying to cs indicating old Czech is illegitimate, and MUST not be granted. 3. ISO can and should add a different subtag that means old Czech I've requested a response from the JAC (through Peter Constable on Jan 11) to clarify this, but have gotten nothing. His opinion was number 2, which seems reasonable, but we really have to know what the situation is for RFC 4646bis! Mark -- Mark ------=_Part_8517_30069797.1171391034548 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I wonder if there is, or is going to be, a public forum to discuss ISO
639-3 and its structure and policies.  This list really isn't it; we
take what the external standards give us, and synthesize and arrange.
We don't directly influence what the external standards do, though there
are list members who can do so indirectly.

That would be very useful. We are very dependent on the interpretation of the codes. In particular, there is a key item that we need a response for, and that is the temporal scope of ISO language codes. For example, we have french broken up into fr, frm, and fro, plus various creoles. So  tagging old French data with fr is incorrect, and requesting a variant subtag to apply to fr to indicate French of say (1100-1200) is out of scope and will be legitimately rejected.

For most other languages, on the other hand, we do not have that granularity. So that means what a document that is tagged with cs (Czech) represents is completely unspecified. We do not know what the !#$@ to do with a request. We are faced with an unknown situation which the ISO committee doesn't respond to.

Assume that old Czech is as different from modern as fro is from fr. There are the following two alternatives:
  1. The subtag 'cs' means any Czech, modern or old, and therefore
    1. cs can legitimately be used to tag a document with old Czech.
    2. a request for a variant-subtag applying to cs indicating old Czech is perfectly reasonable, and SHOULD be granted.
    3. ISO can only add another subtag that means old Czech if cs is treated as a metalanguage, since otherwise that would invalidate old subtags.
  2. The subtag 'cs mean only modern Czech, and therefore
    1. cs cannot be correctly used to tag a document with old Czech, so the only recourse is to use a private use code or 'und'.
    2. a request for a variant-subtag applying to cs indicating old Czech is illegitimate, and MUST not be granted.
    3. ISO can and should add a different subtag that means old Czech
I've requested a response from the JAC (through Peter Constable on Jan 11) to clarify this, but have gotten nothing. His opinion was number 2, which seems reasonable, but we really have to know what the situation is for RFC 4646bis!

Mark


--
Mark ------=_Part_8517_30069797.1171391034548-- --===============0430082526== 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 --===============0430082526==-- From ltru-bounces@ietf.org Tue Feb 13 15:22:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH4Ah-0006W2-5l; Tue, 13 Feb 2007 15:22:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH4Ag-0006VS-35 for ltru@ietf.org; Tue, 13 Feb 2007 15:22:38 -0500 Received: from bay0-omc3-s40.bay0.hotmail.com ([65.54.246.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH4Ac-0004Pt-5z for ltru@ietf.org; Tue, 13 Feb 2007 15:22:37 -0500 Received: from hotmail.com ([65.54.169.49]) by bay0-omc3-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 13 Feb 2007 12:22:33 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Feb 2007 12:22:33 -0800 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Tue, 13 Feb 2007 20:22:29 GMT X-Originating-IP: [209.133.185.129] X-Originating-Email: [cewcathar@hotmail.com] X-Sender: cewcathar@hotmail.com In-Reply-To: <30b660a20702131023k53f09d76r1e37848af4853f1@mail.gmail.com> From: "CE Whitehead" To: mark.davis@icu-project.org Bcc: Date: Tue, 13 Feb 2007 15:22:29 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 13 Feb 2007 20:22:33.0660 (UTC) FILETIME=[B1A37FC0:01C74FAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ietf-languages@iana.org, ltru@ietf.org Subject: [Ltru] Re: Macrolanguages, countries & orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 wonder if there is, or is going to be, a public forum to discuss ISO >>639-3 and its structure and policies. This list really isn't it; we >>take what the external standards give us, and synthesize and arrange. >>We don't directly influence what the external standards do, though there >>are list members who can do so indirectly. > +1 >That would be very useful. We are very dependent on the interpretation of >the codes. In particular, there is a key item that we need a response for, >and that is the temporal scope of ISO language codes. For example, we have >french broken up into fr, frm, and fro, plus various creoles. So tagging >old French data with fr is incorrect, and requesting a variant subtag to >apply to fr to indicate French of say (1100-1200) is out of scope and will >be legitimately rejected. > >For most other languages, on the other hand, we do not have that >granularity. >So that means what a document that is tagged with cs (Czech) represents is >completely unspecified. We do not know what the !#$@ to do with a request. >We are faced with an unknown situation which the ISO committee doesn't >respond to. > _________________________________________________________________ Search for grocery stores. Find gratitude. Turn a simple search into something more. http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_gratitude&FORM=WLMTAG _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 13 16:49:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5Wp-0007kV-Ab; Tue, 13 Feb 2007 16:49:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5Wn-0007jw-IL for ltru@ietf.org; Tue, 13 Feb 2007 16:49:33 -0500 Received: from [64.39.15.8] (helo=kabissa.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH5Wm-0001iS-0r for ltru@ietf.org; Tue, 13 Feb 2007 16:49:33 -0500 Received: (qmail 26830 invoked from network); 13 Feb 2007 15:48:14 -0600 Received: from h-67-100-157-224.mclnva23.covad.net (HELO IBM92AA25595C4) (67.100.157.224) by kabissa.org with SMTP; 13 Feb 2007 15:48:14 -0600 From: "Don Osborn" To: "'Mark Davis'" , "'Doug Ewell'" References: <20070213110003.032CE25970A@eikenes.alvestrand.no> <004101c74f81$345acd50$6401a8c0@DGBP7M81> <30b660a20702131023k53f09d76r1e37848af4853f1@mail.gmail.com> In-Reply-To: <30b660a20702131023k53f09d76r1e37848af4853f1@mail.gmail.com> Date: Tue, 13 Feb 2007 16:48:09 -0500 Message-ID: <049401c74fb8$a82e1e80$f88a5b80$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcdPnTAsSm2Ln1oKQuuVNfNEnIFNKAAGPLaA Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: ietf-languages@iana.org, ltru@ietf.org Subject: [Ltru] RE: Macrolanguages, countries & orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1142996452==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1142996452== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0495_01C74F8E.BF581680" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0495_01C74F8E.BF581680 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 If a new forum on ISO-639 is in the offing it might be worth giving it = the scope of all of ISO-639 and not just part 3, though that is where a = lot of the discussion is at the moment. If 639 is a system of several = parts then inevitably discussion will involve the others; all the more = with the eventual arrival of 5 & 6 and recalibration (or reinvention?) = of 2. =20 On the other hand, I have to say that as one who only relatively = recently joined ietf-languages & ltru that I would almost prefer = recasting one of those to cover ISO-639. Or even to have a new larger = language coding list be mandated to replace the set (hopefully that is = not too heretical). *Another* list to follow is, well, yet another list = to follow. And inevitably it will be cc=E2=80=99d on many messages to = one or more of the other lists anyway.=20 =20 Just thought=E2=80=A6=20 =20 Don =20 =20 From: ietf-languages-bounces@alvestrand.no = [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Mark Davis Sent: Tuesday, February 13, 2007 1:24 PM To: Doug Ewell Cc: ietf-languages@iana.org; ltru@ietf.org Subject: Re: Macrolanguages, countries & orthographies =20 =20 I wonder if there is, or is going to be, a public forum to discuss ISO 639-3 and its structure and policies. This list really isn't it; we=20 take what the external standards give us, and synthesize and arrange. We don't directly influence what the external standards do, though there are list members who can do so indirectly. That would be very useful. We are very dependent on the interpretation = of the codes. In particular, there is a key item that we need a response = for, and that is the temporal scope of ISO language codes. For example, = we have french broken up into fr, frm, and fro, plus various creoles. So = tagging old French data with fr is incorrect, and requesting a variant = subtag to apply to fr to indicate French of say (1100-1200) is out of = scope and will be legitimately rejected.=20 For most other languages, on the other hand, we do not have that = granularity. So that means what a document that is tagged with cs = (Czech) represents is completely unspecified. We do not know what the = !#$@ to do with a request. We are faced with an unknown situation which = the ISO committee doesn't respond to.=20 . . .=20 ------=_NextPart_000_0495_01C74F8E.BF581680 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

If a new forum on ISO-639 is in the offing it might be = worth giving it the scope of all of ISO-639 and not just part 3, though that = is where a lot of the discussion is at the moment. If 639 is a system of several = parts then inevitably discussion will involve the others; all the more with the = eventual arrival of 5 & 6 and recalibration (or reinvention?) of = 2.

 

On the other hand, I have to say that as one who only = relatively recently joined ietf-languages & ltru that I would almost prefer = recasting one of those to cover ISO-639. Or even to have a new larger language = coding list be mandated to replace the set (hopefully that is not too heretical). = *Another* list to follow is, well, yet another list to follow. And inevitably it = will be cc=E2=80=99d on many messages to one or more of the other lists anyway. =

 

Just thought=E2=80=A6

 

Don

 

 

From:= ietf-languages-bounces@alvestrand.no = [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Mark Davis
Sent: Tuesday, February 13, 2007 1:24 PM
To: Doug Ewell
Cc: ietf-languages@iana.org; ltru@ietf.org
Subject: Re: Macrolanguages, countries & = orthographies

 

 

I wonder if there is, or is going to be, a public = forum to discuss ISO
639-3 and its structure and policies.  This list really isn't = it; we
take what the external standards give us, and synthesize and = arrange.
We don't directly influence what the external standards do, though = there
are list members who can do so indirectly.


That would be very useful. We are very dependent on the interpretation = of the codes. In particular, there is a key item that we need a response for, = and that is the temporal scope of ISO language codes. For example, we have french = broken up into fr, frm, and fro, plus various creoles. So  tagging old = French data with fr is incorrect, and requesting a variant subtag to apply to = fr to indicate French of say (1100-1200) is out of scope and will be = legitimately rejected.

For most other languages, on the other hand, we do not have that = granularity. So that means what a document that is tagged with cs (Czech) represents = is completely unspecified. We do not know what the !#$@ to do with a = request. We are faced with an unknown situation which the ISO committee doesn't = respond to.

. . .

------=_NextPart_000_0495_01C74F8E.BF581680-- --===============1142996452== 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 --===============1142996452==-- From ltru-bounces@ietf.org Tue Feb 13 19:22:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH7uS-00023W-4v; Tue, 13 Feb 2007 19:22:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH7uR-00022s-41 for ltru@ietf.org; Tue, 13 Feb 2007 19:22:07 -0500 Received: from ag-out-0708.google.com ([72.14.246.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH7uN-0002Mz-MF for ltru@ietf.org; Tue, 13 Feb 2007 19:22:07 -0500 Received: by ag-out-0708.google.com with SMTP id 8so1549988agc for ; Tue, 13 Feb 2007 16:22:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=MFiKLMiAyqQ+OaQsFzTLReYG2QmRP/W/pCflZnzQVANpmVUXdrFkLQ1WFbrV7jYdEl4K9dFLzIcrRwr6Rp7DD0VvwwvTIxS5uRdW2CFMRjJ1bl/9BhggovnHeZNn/g63BhVnQVf/WI8JF+Z0ix0QKLhyDiqOUPNjpgFCvNRzu7A= Received: by 10.90.84.17 with SMTP id h17mr20252215agb.1171412520642; Tue, 13 Feb 2007 16:22:00 -0800 (PST) Received: by 10.90.50.20 with HTTP; Tue, 13 Feb 2007 16:22:00 -0800 (PST) Message-ID: <30b660a20702131622g2a3f7c4bu5651b3e7dd575075@mail.gmail.com> Date: Tue, 13 Feb 2007 16:22:00 -0800 From: "Mark Davis" To: "Lars Aronsson" In-Reply-To: MIME-Version: 1.0 References: <20070213110003.032CE25970A@eikenes.alvestrand.no> <004101c74f81$345acd50$6401a8c0@DGBP7M81> <30b660a20702131023k53f09d76r1e37848af4853f1@mail.gmail.com> X-Google-Sender-Auth: 87f440caedb5d76e X-Spam-Score: 0.5 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ietf-languages@iana.org, LTRU Working Group Subject: [Ltru] Re: Macrolanguages, countries & orthographies X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0438974511==" Errors-To: ltru-bounces@ietf.org --===============0438974511== Content-Type: multipart/alternative; boundary="----=_Part_18968_5034718.1171412520504" ------=_Part_18968_5034718.1171412520504 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Saying that it is not as important is, I agree, your prejudice. Importance is in the eye of the beholder, and ISO 639-3 has 7,500 languages, which make distinctions that to people concerned with Czech will be far less important than the difference between old Czech and modern Czech. Moreover, one cannot fixate on the exact example used. There are plenty of others, because very few languages have "Old" variants in 639-3. The principle is the same for any other language: do we presume that the code means only the modern variant, or covers all historical variations? We need to get an answer for that; without that answer, we can't know whether to accept or reject historic variant proposals. Mark On 2/13/07, Lars Aronsson wrote: > > Mark Davis wrote: > > > Assume that old Czech is as different from modern as fro is from fr. > > But is this a real problem? How much total literature is written > and available in different variations of Czech? My prejudice says > that as a nation with a language and literature of its own, Czech > is about as young as Finnish, Norwegian or Serbian, i.e. 19th > century. Can you give any concrete examples when not having a > separate *code* for pre-renaissance Czech is a practical problem? > > Linguists of course have *names* for Swedish of all ages, but I > see no real use for having ISO or the IETF specify language > *codes*. I could be wrong, but if so please enlighten and correct > me. Nobody is going to translate OpenOffice or Mozilla to the > language spoken by vikings (Old Norse) or the Swedish used during > the Lutheran reformation (called New Swedish, ironically). > > Yes, there is now a branch of Wikipedia in Old English > (ang.wikipedia.org), but that is a rare exception. I don't expect > this to happen in other languages. Ang has now 744 articles, > compared to the 11,000 articles of the Latin Wikipedia. > > I'm scanning old books, and I'm starting to see a practical > problem with different orthographies and spelling reforms, similar > to those addressed with the IETF defined codes for German de-1901 > and de-1996. Analogous to these codes, we could perhaps find use > for sv-1801, sv-1889, sv-1906, da-1775, da-1892 and da-1948, > because we now have *significant amounts* of text online in each > of these language versions. But before 1775/1801 the orthography > of Swedish and Danish varies so heavily with each work, that it > becomes pretty much useless to try to identify more versions. > And before that time, there is also so small amounts of literature > available, that any automatic processing becomes insignificant. > > > > -- > Lars Aronsson (lars@aronsson.se) > Aronsson Datateknik - http://aronsson.se > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages > -- Mark ------=_Part_18968_5034718.1171412520504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Saying that it is not as important is, I agree, your prejudice. Importance is in the eye of the beholder, and ISO 639-3 has 7,500 languages, which make distinctions that to people concerned with Czech will be far less important than the difference between old Czech and modern Czech.

Moreover, one cannot fixate on the exact example used. There are plenty of others, because very few languages have "Old" variants in 639-3. The principle is the same for any other language: do we presume that the code means only the modern variant, or covers all historical variations? We need to get an answer for that; without that answer, we can't know whether to accept or reject historic variant proposals.

Mark

On 2/13/07, Lars Aronsson <lars@aronsson.se> wrote:
Mark Davis wrote:

> Assume that old Czech is as different from modern as fro is from fr.

But is this a real problem?  How much total literature is written
and available in different variations of Czech?  My prejudice says
that as a nation with a language and literature of its own, Czech
is about as young as Finnish, Norwegian or Serbian, i.e. 19th
century.  Can you give any concrete examples when not having a
separate *code* for pre-renaissance Czech is a practical problem?

Linguists of course have *names* for Swedish of all ages, but I
see no real use for having ISO or the IETF specify language
*codes*.  I could be wrong, but if so please enlighten and correct
me.  Nobody is going to translate OpenOffice or Mozilla to the
language spoken by vikings (Old Norse) or the Swedish used during
the Lutheran reformation (called New Swedish, ironically).

Yes, there is now a branch of Wikipedia in Old English
( ang.wikipedia.org), but that is a rare exception.  I don't expect
this to happen in other languages.  Ang has now 744 articles,
compared to the 11,000 articles of the Latin Wikipedia.

I'm scanning old books, and I'm starting to see a practical
problem with different orthographies and spelling reforms, similar
to those addressed with the IETF defined codes for German de-1901
and de-1996.  Analogous to these codes, we could perhaps find use
for sv-1801, sv-1889, sv-1906, da-1775, da-1892 and da-1948,
because we now have *significant amounts* of text online in each
of these language versions. But before 1775/1801 the orthography
of Swedish and Danish varies so heavily with each work, that it
becomes pretty much useless to try to identify more versions.
And before that time, there is also so small amounts of literature
available, that any automatic processing becomes insignificant.



--
  Lars Aronsson (lars@aronsson.se )
  Aronsson Datateknik - http://aronsson.se
_______________________________________________
Ietf-languages mailing list
Ietf-languages@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages



--
Mark ------=_Part_18968_5034718.1171412520504-- --===============0438974511== 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 --===============0438974511==-- From ltru-bounces@ietf.org Tue Feb 13 21:18:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH9ie-00004y-EH; Tue, 13 Feb 2007 21:18:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH9ic-00004s-TX for ltru@ietf.org; Tue, 13 Feb 2007 21:18:02 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH9iV-0000Re-5p for ltru@ietf.org; Tue, 13 Feb 2007 21:18:02 -0500 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 14 Feb 2007 02:17:41 +0000 From: "Debbie Garside" To: , "'Lars Aronsson'" Subject: RE: [Ltru] Re: Macrolanguages, countries & orthographies Date: Wed, 14 Feb 2007 02:17:32 -0000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcdPznDw7h8A8MHRQuC1+Nu2jJ/Q3gADr0gQ In-Reply-To: <30b660a20702131622g2a3f7c4bu5651b3e7dd575075@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: ietf-languages@iana.org, 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2097371129==" Errors-To: ltru-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============2097371129== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0127_01C74FDE.491EFC90" This is a multi-part message in MIME format. ------=_NextPart_000_0127_01C74FDE.491EFC90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mark wrote: >> The principle is the same for any other language: do we presume that the code means only the modern variant, or covers all historical variations? We need to get an answer for that; without that answer, we can't know whether to accept or reject historic variant proposals. My personal opinion is that ISO 639-3 subtags cover the "whole language" as described; all of the language, every part of the language, written and spoken and... historical. Even when there is an ISO 639-3 historical subtag that covers part of it. My advice, accept urgent proposals for historic variants on the basis that they will be deprecated when ISO 639-6 comes into being - assuming it is incorporated within RFC4646bis or ter. Inform proposers of such variants that ISO 639-6 is currently being designed and if the need is not urgent delay until ISO 639-6 is published. I think this group needs to make a decision wrt ISO 639-6. Best regards Debbie _____ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: 14 February 2007 00:22 To: Lars Aronsson Cc: ietf-languages@iana.org; LTRU Working Group Subject: [Ltru] Re: Macrolanguages, countries & orthographies Saying that it is not as important is, I agree, your prejudice. Importance is in the eye of the beholder, and ISO 639-3 has 7,500 languages, which make distinctions that to people concerned with Czech will be far less important than the difference between old Czech and modern Czech. Moreover, one cannot fixate on the exact example used. There are plenty of others, because very few languages have "Old" variants in 639-3. The principle is the same for any other language: do we presume that the code means only the modern variant, or covers all historical variations? We need to get an answer for that; without that answer, we can't know whether to accept or reject historic variant proposals. Mark On 2/13/07, Lars Aronsson wrote: Mark Davis wrote: > Assume that old Czech is as different from modern as fro is from fr. But is this a real problem? How much total literature is written and available in different variations of Czech? My prejudice says that as a nation with a language and literature of its own, Czech is about as young as Finnish, Norwegian or Serbian, i.e. 19th century. Can you give any concrete examples when not having a separate *code* for pre-renaissance Czech is a practical problem? Linguists of course have *names* for Swedish of all ages, but I see no real use for having ISO or the IETF specify language *codes*. I could be wrong, but if so please enlighten and correct me. Nobody is going to translate OpenOffice or Mozilla to the language spoken by vikings (Old Norse) or the Swedish used during the Lutheran reformation (called New Swedish, ironically). Yes, there is now a branch of Wikipedia in Old English ( ang.wikipedia.org ), but that is a rare exception. I don't expect this to happen in other languages. Ang has now 744 articles, compared to the 11,000 articles of the Latin Wikipedia. I'm scanning old books, and I'm starting to see a practical problem with different orthographies and spelling reforms, similar to those addressed with the IETF defined codes for German de-1901 and de-1996. Analogous to these codes, we could perhaps find use for sv-1801, sv-1889, sv-1906, da-1775, da-1892 and da-1948, because we now have *significant amounts* of text online in each of these language versions. But before 1775/1801 the orthography of Swedish and Danish varies so heavily with each work, that it becomes pretty much useless to try to identify more versions. And before that time, there is also so small amounts of literature available, that any automatic processing becomes insignificant. -- Lars Aronsson (lars@aronsson.se ) Aronsson Datateknik - http://aronsson.se _______________________________________________ Ietf-languages mailing list Ietf-languages@alvestrand.no http://www.alvestrand.no/mailman/listinfo/ietf-languages -- Mark ------=_NextPart_000_0127_01C74FDE.491EFC90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Mark=20 wrote:
 
>> The principle is the same = for any=20 other language: do we presume that the code means only the modern = variant, or=20 covers all historical variations? We need to get an answer for that; = without=20 that answer, we can't know whether to accept or reject historic variant=20 proposals.
 
My=20 personal opinion is that ISO 639-3 subtags cover the "whole language" as = described; all of the language, every part of the language, written and = spoken=20 and... historical.  Even when there is an ISO 639-3 historical = subtag=20 that covers part of it.
 
My=20 advice, accept urgent proposals for historic variants on the basis that = they=20 will be deprecated when ISO 639-6 comes into being - assuming it is = incorporated=20 within RFC4646bis or ter.  Inform proposers of such variants that = ISO 639-6=20 is currently being designed and if the need is not urgent delay until = ISO 639-6=20 is published.
 
I=20 think this group needs to make a decision wrt ISO 639-6. =20
 
Best=20 regards
 
Debbie

 

From: Mark Davis=20 [mailto:mark.davis@icu-project.org]
Sent: 14 February 2007=20 00:22
To: Lars Aronsson
Cc: = ietf-languages@iana.org; LTRU=20 Working Group
Subject: [Ltru] Re: Macrolanguages, countries = &=20 orthographies

Saying that it is not as important is, I agree, your = prejudice.=20 Importance is in the eye of the beholder, and ISO 639-3 has 7,500 = languages,=20 which make distinctions that to people concerned with Czech will be = far less=20 important than the difference between old Czech and modern Czech.=20

Moreover, one cannot fixate = on the=20 exact example used. There are plenty of others, because very = few=20 languages have "Old" variants in 639-3. The principle is the same for = any=20 other language: do we presume that the code means only the modern = variant, or=20 covers all historical variations? We need to get an answer for that; = without=20 that answer, we can't know whether to accept or reject historic = variant=20 proposals.

Mark

On 2/13/07, Lars=20 Aronsson <lars@aronsson.se>=20 wrote:
Mark=20 Davis wrote:

> Assume that old Czech is as different from = modern=20 as fro is from fr.

But is this a real problem?  How = much=20 total literature is written
and available in different variations = of=20 Czech?  My prejudice says
that as a nation with a = language and=20 literature of its own, Czech
is about as young as Finnish, = Norwegian or=20 Serbian, i.e. 19th
century.  Can you give any concrete = examples=20 when not having a
separate *code* for pre-renaissance Czech is a=20 practical problem?

Linguists of course have *names* for = Swedish of=20 all ages, but I
see no real use for having ISO or the IETF = specify=20 language
*codes*.  I could be wrong, but if so please = enlighten=20 and correct
me.  Nobody is going to translate = OpenOffice or=20 Mozilla to the
language spoken by vikings (Old Norse) or the = Swedish=20 used during
the Lutheran reformation (called New Swedish,=20 ironically).

Yes, there is now a branch of Wikipedia in Old=20 English
( = ang.wikipedia.org), but=20 that is a rare exception.  I don't expect
this to = happen in=20 other languages.  Ang has now 744 articles,
compared to = the=20 11,000 articles of the Latin Wikipedia.

I'm scanning old = books, and=20 I'm starting to see a practical
problem with different = orthographies and=20 spelling reforms, similar
to those addressed with the IETF = defined codes=20 for German de-1901
and de-1996.  Analogous to these = codes, we=20 could perhaps find use
for sv-1801, sv-1889, sv-1906, da-1775, = da-1892=20 and da-1948,
because we now have *significant amounts* of text = online in=20 each
of these language versions. But before 1775/1801 the=20 orthography
of Swedish and Danish varies so heavily with each = work, that=20 it
becomes pretty much useless to try to identify more versions. =
And=20 before that time, there is also so small amounts of = literature
available,=20 that any automatic processing becomes=20 insignificant.



--
  Lars Aronsson (lars@aronsson.se=20 )
  Aronsson Datateknik - http://aronsson.se
___________________= ____________________________
Ietf-languages=20 mailing list
Ietf-languages@alvestrand.no= =20
http://= www.alvestrand.no/mailman/listinfo/ietf-languages


--
Mark ------=_NextPart_000_0127_01C74FDE.491EFC90-- --===============2097371129== 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 --===============2097371129==-- From ltru-bounces@ietf.org Tue Feb 13 21:50:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHAEB-0003XP-Rd; Tue, 13 Feb 2007 21:50:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHAEB-0003XG-3H for ltru@ietf.org; Tue, 13 Feb 2007 21:50:39 -0500 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHAE8-0004oP-Dv for ltru@ietf.org; Tue, 13 Feb 2007 21:50:39 -0500 Received: by wx-out-0506.google.com with SMTP id h31so45695wxd for ; Tue, 13 Feb 2007 18:50:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=cRLO6i9uMwBQYS3gYEGBAFi94NlD+dgoQLn+W3NzowlJ/DpcP83qY/Tgi5s9RqF5XoishEbXnZ9ylBB/TEEqkX44NwWorpV+d2LvgP7AxqViILORjvUryog1eKGFzS+nRthYmR3OdEiyw7cKosrN7AICA4XQLbBDOSx02hjdC74= Received: by 10.90.103.2 with SMTP id a2mr20295756agc.1171421433420; Tue, 13 Feb 2007 18:50:33 -0800 (PST) Received: by 10.90.50.20 with HTTP; Tue, 13 Feb 2007 18:50:33 -0800 (PST) Message-ID: <30b660a20702131850m6b045226q9229a98529d02f6a@mail.gmail.com> Date: Tue, 13 Feb 2007 18:50:33 -0800 From: "Mark Davis" To: "Debbie Garside" Subject: Re: [Ltru] Re: Macrolanguages, countries & orthographies In-Reply-To: <45d2714f.311f7d7e.4ffe.2491SMTPIN_ADDED@mx.google.com> MIME-Version: 1.0 References: <30b660a20702131622g2a3f7c4bu5651b3e7dd575075@mail.gmail.com> <45d2714f.311f7d7e.4ffe.2491SMTPIN_ADDED@mx.google.com> X-Google-Sender-Auth: a6251e84774abc60 X-Spam-Score: 0.1 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 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="===============1822027942==" Errors-To: ltru-bounces@ietf.org --===============1822027942== Content-Type: multipart/alternative; boundary="----=_Part_21814_33142202.1171421433115" ------=_Part_21814_33142202.1171421433115 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 1. Your personal opinion contradicts what I heard as a rough consensus earlier, that fr is not a superset of fro or frm. The highest priority is that the interpretation be well-defined and consistent; I think your opinion would be reasonable, but it doesn't seem to be the consensus. 2. If you asked me right now up-or-down on ISO 649-6, I'd say absolutely not, since (a) it would introduce all kinds of duplicate encodings, and (b) there has been no clear rationale given that the other information is worth adding. For example, the second two of these, from your example, would be duplicates. kca obgc Khanty kcal kcaw Khanty Written Latin Script kcac kcaw Khanty Written Cyrillic Script The only justification I've seen is that " Needless to say, I think there is a need for ISO 639-6 within this RFC. There is a need for variants. There is a need for a hierarchical system that will facilitate the creation of pick lists; 7,200 entities are more than a little unwieldy for the end user when setting language preferences!" But as per earlier messages, end users have very little idea of language taxonomies. A far better interface for narrowing choices would be one that lets them pick a country, and then languages in use in the country. But all of that is beside the point -- UI is *not* the goal of BCP 47. A hierarchy of languages may well be useful in some circumstances, but it is orthogonal to the requirements of BCP 47. Mark On 2/13/07, Debbie Garside wrote: > > Mark wrote: > > >> The principle is the same for any other language: do we presume that > the code means only the modern variant, or covers all historical variations? > We need to get an answer for that; without that answer, we can't know > whether to accept or reject historic variant proposals. > > My personal opinion is that ISO 639-3 subtags cover the "whole language" > as described; all of the language, every part of the language, written and > spoken and... historical. Even when there is an ISO 639-3 historical subtag > that covers part of it. > > My advice, accept urgent proposals for historic variants on the basis that > they will be deprecated when ISO 639-6 comes into being - assuming it is > incorporated within RFC4646bis or ter. Inform proposers of such variants > that ISO 639-6 is currently being designed and if the need is not urgent > delay until ISO 639-6 is published. > > I think this group needs to make a decision wrt ISO 639-6. > > Best regards > > Debbie > > > > ------------------------------ > *From:* Mark Davis [mailto:mark.davis@icu-project.org] > *Sent:* 14 February 2007 00:22 > *To:* Lars Aronsson > *Cc:* ietf-languages@iana.org; LTRU Working Group > *Subject:* [Ltru] Re: Macrolanguages, countries & orthographies > > Saying that it is not as important is, I agree, your prejudice. Importance > is in the eye of the beholder, and ISO 639-3 has 7,500 languages, which make > distinctions that to people concerned with Czech will be far less important > than the difference between old Czech and modern Czech. > > Moreover, one cannot fixate on the exact example used. There are plenty of > others, because very few languages have "Old" variants in 639-3. The > principle is the same for any other language: do we presume that the code > means only the modern variant, or covers all historical variations? We need > to get an answer for that; without that answer, we can't know whether to > accept or reject historic variant proposals. > > Mark > > On 2/13/07, Lars Aronsson wrote: > > > > Mark Davis wrote: > > > > > Assume that old Czech is as different from modern as fro is from fr. > > > > But is this a real problem? How much total literature is written > > and available in different variations of Czech? My prejudice says > > that as a nation with a language and literature of its own, Czech > > is about as young as Finnish, Norwegian or Serbian, i.e. 19th > > century. Can you give any concrete examples when not having a > > separate *code* for pre-renaissance Czech is a practical problem? > > > > Linguists of course have *names* for Swedish of all ages, but I > > see no real use for having ISO or the IETF specify language > > *codes*. I could be wrong, but if so please enlighten and correct > > me. Nobody is going to translate OpenOffice or Mozilla to the > > language spoken by vikings (Old Norse) or the Swedish used during > > the Lutheran reformation (called New Swedish, ironically). > > > > Yes, there is now a branch of Wikipedia in Old English > > ( ang.wikipedia.org), but that is a rare exception. I don't expect > > this to happen in other languages. Ang has now 744 articles, > > compared to the 11,000 articles of the Latin Wikipedia. > > > > I'm scanning old books, and I'm starting to see a practical > > problem with different orthographies and spelling reforms, similar > > to those addressed with the IETF defined codes for German de-1901 > > and de-1996. Analogous to these codes, we could perhaps find use > > for sv-1801, sv-1889, sv-1906, da-1775, da-1892 and da-1948, > > because we now have *significant amounts* of text online in each > > of these language versions. But before 1775/1801 the orthography > > of Swedish and Danish varies so heavily with each work, that it > > becomes pretty much useless to try to identify more versions. > > And before that time, there is also so small amounts of literature > > available, that any automatic processing becomes insignificant. > > > > > > > > -- > > Lars Aronsson (lars@aronsson.se ) > > Aronsson Datateknik - http://aronsson.se > > _______________________________________________ > > Ietf-languages mailing list > > Ietf-languages@alvestrand.no > > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > > > -- > Mark > > -- Mark ------=_Part_21814_33142202.1171421433115 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 1. Your personal opinion contradicts what I heard as a rough consensus earlier, that fr is not a superset of fro or frm. The highest priority is that the interpretation be well-defined and consistent; I think your opinion would be reasonable, but it doesn't seem to be the consensus.

2. If you asked me right now up-or-down on ISO 649-6, I'd say absolutely not, since (a) it would introduce all kinds of duplicate encodings, and (b) there has been no clear rationale given that the other information is worth adding.

For example, the second two of these, from your example, would be duplicates.
kca     obgc    Khanty
kcal    kcaw    Khanty Written Latin Script
kcac    kcaw    Khanty Written Cyrillic Script

The only justification I've seen is that " Needless to say, I think
there is a need for ISO 639-6 within this RFC.  There is a need for
variants.  There is a need for a hierarchical system that will facilitate
the creation of pick lists; 7,200 entities are more than a little unwieldy
for the end user when setting language preferences!"

But as per earlier messages, end users have very little idea of language taxonomies. A far better interface for narrowing choices would be one that lets them pick a country, and then languages in use in the country. But all of that is beside the point -- UI is *not* the goal of BCP 47.

A hierarchy of languages may well be useful in some circumstances, but it is orthogonal to the requirements of BCP 47.

Mark

On 2/13/07, Debbie Garside <debbie@ictmarketing.co.uk> wrote:
Mark wrote:
 
>> The principle is the same for any other language: do we presume that the code means only the modern variant, or covers all historical variations? We need to get an answer for that; without that answer, we can't know whether to accept or reject historic variant proposals.
 
My personal opinion is that ISO 639-3 subtags cover the "whole language" as described; all of the language, every part of the language, written and spoken and... historical.  Even when there is an ISO 639-3 historical subtag that covers part of it.
 
My advice, accept urgent proposals for historic variants on the basis that they will be deprecated when ISO 639-6 comes into being - assuming it is incorporated within RFC4646bis or ter.  Inform proposers of such variants that ISO 639-6 is currently being designed and if the need is not urgent delay until ISO 639-6 is published.
 
I think this group needs to make a decision wrt ISO 639-6. 
 
Best regards
 
Debbie

 

From: Mark Davis [mailto:mark.davis@icu-project.org]
Sent: 14 February 2007 00:22
To: Lars Aronsson
Cc: ietf-languages@iana.org; LTRU Working Group
Subject: [Ltru] Re: Macrolanguages, countries & orthographies

Saying that it is not as important is, I agree, your prejudice. Importance is in the eye of the beholder, and ISO 639-3 has 7,500 languages, which make distinctions that to people concerned with Czech will be far less important than the difference between old Czech and modern Czech.

Moreover, one cannot fixate on the exact example used. There are plenty of others, because very few languages have "Old" variants in 639-3. The principle is the same for any other language: do we presume that the code means only the modern variant, or covers all historical variations? We need to get an answer for that; without that answer, we can't know whether to accept or reject historic variant proposals.

Mark

On 2/13/07, Lars Aronsson <lars@aronsson.se> wrote:
Mark Davis wrote:

> Assume that old Czech is as different from modern as fro is from fr.

But is this a real problem?  How much total literature is written
and available in different variations of Czech?  My prejudice says
that as a nation with a language and literature of its own, Czech
is about as young as Finnish, Norwegian or Serbian, i.e. 19th
century.  Can you give any concrete examples when not having a
separate *code* for pre-renaissance Czech is a practical problem?

Linguists of course have *names* for Swedish of all ages, but I
see no real use for having ISO or the IETF specify language
*codes*.  I could be wrong, but if so please enlighten and correct
me.  Nobody is going to translate OpenOffice or Mozilla to the
language spoken by vikings (Old Norse) or the Swedish used during
the Lutheran reformation (called New Swedish, ironically).

Yes, there is now a branch of Wikipedia in Old English
( ang.wikipedia.org), but that is a rare exception.  I don't expect
this to happen in other languages.  Ang has now 744 articles,
compared to the 11,000 articles of the Latin Wikipedia.

I'm scanning old books, and I'm starting to see a practical
problem with different orthographies and spelling reforms, similar
to those addressed with the IETF defined codes for German de-1901
and de-1996.  Analogous to these codes, we could perhaps find use
for sv-1801, sv-1889, sv-1906, da-1775, da-1892 and da-1948,
because we now have *significant amounts* of text online in each
of these language versions. But before 1775/1801 the orthography
of Swedish and Danish varies so heavily with each work, that it
becomes pretty much useless to try to identify more versions.
And before that time, there is also so small amounts of literature
available, that any automatic processing becomes insignificant.



--
  Lars Aronsson (lars@aronsson.se )
  Aronsson Datateknik - http://aronsson.se
_______________________________________________
Ietf-languages mailing list
Ietf-languages@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages



--
Mark



--
Mark ------=_Part_21814_33142202.1171421433115-- --===============1822027942== 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 --===============1822027942==-- From ltru-bounces@ietf.org Tue Feb 13 22:13:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHAaN-0000HG-9e; Tue, 13 Feb 2007 22:13:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHAaL-0000HB-7l for ltru@ietf.org; Tue, 13 Feb 2007 22:13:33 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHAaI-00075d-OF for ltru@ietf.org; Tue, 13 Feb 2007 22:13:33 -0500 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 14 Feb 2007 03:13:27 +0000 From: "Debbie Garside" To: Subject: RE: [Ltru] Re: Macrolanguages, countries & orthographies Date: Wed, 14 Feb 2007 03:13:18 -0000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcdP420a1nXEZt0+SHybLaqHI0+/PQAAEm3w In-Reply-To: <30b660a20702131850m6b045226q9229a98529d02f6a@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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="===============0424419650==" Errors-To: ltru-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============0424419650== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0134_01C74FE6.1393BC70" This is a multi-part message in MIME format. ------=_NextPart_000_0134_01C74FE6.1393BC70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mark wrote: 1. Your personal opinion contradicts what I heard as a rough consensus earlier, that fr is not a superset of fro or frm. The highest priority is that the interpretation be well-defined and consistent; I think your opinion would be reasonable, but it doesn't seem to be the consensus. Thank you. May be we should work on making it consensus. 2. If you asked me right now up-or-down on ISO 649-6, I'd say absolutely not, since (a) it would introduce all kinds of duplicate encodings, I believe we worked out a system of flagging the ISO 639-6 data in order that duplicate encodings would not be introduced within the Registry; a simple procedure which is currently being actioned by GeoLang (compilers of the ISO 639-6 data). and (b) there has been no clear rationale given that the other information is worth adding. Hmmm... I thought we were having a discussion on variants and historical variants, something that is facilitated by the proposed ISO 639-6 code. [snip]But as per earlier messages, end users have very little idea of language taxonomies. A far better interface for narrowing choices would be one that lets them pick a country, and then languages in use in the country. But all of that is beside the point -- UI is *not* the goal of BCP 47. But if one can have both... a faceted approach... what a winner :-) BTW FYI, ISO 639-6 data is also linked to ISO 3166-1 and ISO 15924. I believe we have had the discussion wrt numbers of language selections in some countries but I can certainly see that in some cases this would be preferable. Tell me, hypothetical scenario, what would you recommend a user to do when their language is not listed under their country of residence as there are only two speakers of Khanty residing in the UK? Just a thought. The biggest problem on the score of pick lists is that language names and country names in the users language are required; linked to the ISO 639/3166-1 code. Best Debbie ------=_NextPart_000_0134_01C74FE6.1393BC70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Mark=20 wrote:
 
1. Your personal opinion = contradicts what I=20 heard as a rough consensus earlier, that fr is not a superset of fro or = frm. The=20 highest priority is that the interpretation be well-defined and = consistent; I=20 think your opinion would be reasonable, but it doesn't seem to be the = consensus.=20
 
Thank you.  May be&= nbsp;we should work on making it consensus.=
 
2. If you asked me right now = up-or-down on ISO=20 649-6, I'd say absolutely not, since (a) it would introduce all kinds of = duplicate encodings,
 
I=20 believe we worked out a system of flagging the ISO 639-6 data in order = that=20 duplicate encodings would not be introduced within the Registry; a = simple=20 procedure which is currently being actioned by GeoLang (compilers of the = ISO=20 639-6 data).
 
and (b) there has been no clear rationale given that the other = information=20 is worth adding.
 
Hmmm... = I thought we=20 were having a discussion on variants and historical variants, something = that is=20 facilitated by the proposed ISO 639-6=20 code.
[snip]But as per earlier = messages,=20 end users have very little idea of language taxonomies. A far better = interface=20 for narrowing choices would be one that lets them pick a country, and = then=20 languages in use in the country. But all of that is beside the point -- = UI is=20 *not* the goal of BCP 47.
 
But if=20 one can have both... a faceted approach... what a = winner :-)  BTW=20 FYI, ISO 639-6 data is also linked to ISO 3166-1 and ISO 15924.  I = believe=20 we have had the discussion wrt numbers of language selections in some = countries=20 but I can certainly see that in some cases this would be = preferable.  Tell=20 me, hypothetical scenario, what would you recommend a user to do = when their=20 language is not listed under their country of residence as there = are only=20 two speakers of Khanty residing in the UK?  Just a thought. =20
 
The=20 biggest problem on the score of pick lists is that language names = and=20 country names in the users language are required; linked to = the ISO=20 639/3166-1 code. 
 
Best=20
 
Debbie
------=_NextPart_000_0134_01C74FE6.1393BC70-- --===============0424419650== 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 --===============0424419650==-- From ltru-bounces@ietf.org Tue Feb 13 22:36:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHAwh-0005OC-6M; Tue, 13 Feb 2007 22:36:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHAwg-0005O7-V0 for ltru@ietf.org; Tue, 13 Feb 2007 22:36:38 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHAwf-0001Hg-NC for ltru@ietf.org; Tue, 13 Feb 2007 22:36:38 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HHAwf-0005Vk-90; Tue, 13 Feb 2007 22:36:37 -0500 Date: Tue, 13 Feb 2007 22:36:37 -0500 To: Mark Davis Subject: Re: [Ltru] Re: Macrolanguages, countries & orthographies Message-ID: <20070214033637.GF24776@mercury.ccil.org> References: <30b660a20702131622g2a3f7c4bu5651b3e7dd575075@mail.gmail.com> <45d2714f.311f7d7e.4ffe.2491SMTPIN_ADDED@mx.google.com> <30b660a20702131850m6b045226q9229a98529d02f6a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20702131850m6b045226q9229a98529d02f6a@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > 2. If you asked me right now up-or-down on ISO 639-6, I'd say absolutely > not, since (a) it would introduce all kinds of duplicate encodings, and > (b) there has been no clear rationale given that the other information > is worth adding. Let me reiterate my proposal on 693-6: discard all the codes except those in the following two classes: A) Code elements which represent collections and are not subordinate to any 639-2 collection code element. B) Code elements which represent variants that are subordinate to code elements that are equivalent to some language-script-region 4646 tag. Class A code elements are made into 4-letter initial subtags (currently reserved). Class B code elements are made into variant subtags by prepending a '6' (not '6-') to the code element. This is artificial, but it satisfies the 4646 syntax. > For example, the second two of these, from your example, would be > duplicates. > kca obgc Khanty > kcal kcaw Khanty Written Latin Script > kcac kcaw Khanty Written Cyrillic Script Indeed, and none would be added under my proposal, since they are equivalent to "kca", "kca-Latn", and "kca-Cyrl" respectively. > A hierarchy of languages may well be useful in some circumstances, > but it is orthogonal to the requirements of BCP 47. Indeed. I don't see any need for the hierarchical information in RFC 4646bis or -ter. -- Even a refrigerator can conform to the XML John Cowan Infoset, as long as it has a door sticker cowan@ccil.org saying "No information items inside". http://www.ccil.org/~cowan --Eve Maler _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 14 03:25:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHFSJ-0006oh-BY; Wed, 14 Feb 2007 03:25:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHFSH-0006mu-EB for ltru@ietf.org; Wed, 14 Feb 2007 03:25:33 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHFSG-0005s1-5t for ltru@ietf.org; Wed, 14 Feb 2007 03:25:33 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070214082525.JXIK28666.mta9.adelphia.net@DGBP7M81> for ; Wed, 14 Feb 2007 03:25:25 -0500 Message-ID: <002501c75011$ad023e60$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 14 Feb 2007 00:25:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] "Placeholder" dates in draft Regsitry (was: Re: Progress) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Marion Gunn wrote: > Personally, I feel that adding an artificial date only worsens the > confusion of genuine and other errors. As an Archivist, I felt > comfortable enough adding "g.d." (abbreviation in Irish for "undated") > to entries _sans- known date of publication. I think following that > principle/convention (which is accepted internationally), would help. Does anyone else feel this would help? Is the abbreviation "g.d." really accepted internationally, or only in Irish-speaking communities? Personally, I'm open to suggestions on this, as long as I can tell the "real" dates from the placeholders and there is no risk that the placeholders will end up in the Registry without a chance to fix them at or before publication time. -- 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 Feb 14 07:05:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHIsx-0003pS-Pf; Wed, 14 Feb 2007 07:05:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHIsx-0003m4-2l for ltru@ietf.org; Wed, 14 Feb 2007 07:05:19 -0500 Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHIsu-0002gC-QJ for ltru@ietf.org; Wed, 14 Feb 2007 07:05:19 -0500 Received: (qmail 14611 messnum 2903562 invoked from network[194.125.174.107/ts09-107.dublin.indigo.ie]); 14 Feb 2007 12:05:07 -0000 Received: from ts09-107.dublin.indigo.ie (HELO ?194.125.174.107?) (194.125.174.107) by mail07.svc.cra.dublin.eircom.net (qp 14611) with SMTP; 14 Feb 2007 12:05:07 -0000 In-Reply-To: <002501c75011$ad023e60$6401a8c0@DGBP7M81> References: <002501c75011$ad023e60$6401a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] "Placeholder" dates in draft Regsitry (was: Re: Progress) Date: Wed, 14 Feb 2007 12:07:42 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Sorry - didn't think that open to misinterpretation! - "g.d." is only =20= the Irish expression of a principle/convention accepted =20 internationaly in cataloguing books and manuscripts. My suggestion: =20 find an expression to suit the LTRU context (a better placeholder =20 than a fictitious date). Hope this helps, mg On 14 Feb 2007, at 08:25, scr=EDobh Doug Ewell: > Marion Gunn wrote: > > >> Personally, I feel that adding an artificial date only worsens the =20= >> confusion of genuine and other errors. As an Archivist, I felt =20 >> comfortable enough adding "g.d." (abbreviation in Irish for =20 >> "undated") to entries _sans- known date of publication. I think =20 >> following that principle/convention (which is accepted =20 >> internationally), would help. >> > > Does anyone else feel this would help? Is the abbreviation "g.d." =20 > really accepted internationally, or only in Irish-speaking =20 > communities? > > Personally, I'm open to suggestions on this, as long as I can tell =20 > the "real" dates from the placeholders and there is no risk that =20 > the placeholders will end up in the Registry without a chance to =20 > fix them at or before publication time - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 14 08:06:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHJpt-0003Pz-UG; Wed, 14 Feb 2007 08:06:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHJpt-0003Pu-GV for ltru@ietf.org; Wed, 14 Feb 2007 08:06:13 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHJps-0002VL-7F for ltru@ietf.org; Wed, 14 Feb 2007 08:06:13 -0500 Received: by ug-out-1314.google.com with SMTP id 72so188990ugd for ; Wed, 14 Feb 2007 05:06:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RJNgJW1sPehGbSdcoP+pXwizOx1KEdVZYfegJrcUtivycVf8yPWFogfKCyAeC3/32VmgsZ1XmvNPRDG1agpeuTwB7hJmnWM+FJYfl9+/E5DHNvGpbBRr7JReDWLORLLgeOaLgv9oix6i7mZBuQfRrxiXJvHctm8MzZLPdQ/jrdY= Received: by 10.114.13.1 with SMTP id 1mr73637wam.1171458366034; Wed, 14 Feb 2007 05:06:06 -0800 (PST) Received: by 10.114.12.2 with HTTP; Wed, 14 Feb 2007 05:06:05 -0800 (PST) Message-ID: <6d99d1fd0702140506u5c32e433q5dc92462066d465@mail.gmail.com> Date: Wed, 14 Feb 2007 07:06:05 -0600 From: "David Starner" To: "Debbie Garside" Subject: Re: [Ltru] Re: Macrolanguages, countries & orthographies In-Reply-To: <200702140517.l1E5Hheo008149@pechora3.icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <30b660a20702131622g2a3f7c4bu5651b3e7dd575075@mail.gmail.com> <200702140517.l1E5Hheo008149@pechora3.icann.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf-languages@iana.org, Lars Aronsson , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 2/13/07, Debbie Garside wrote: > My personal opinion is that ISO 639-3 subtags cover the "whole language" as > described; all of the language, every part of the language, written and > spoken and... historical. Even when there is an ISO 639-3 historical subtag > that covers part of it. As a user of en, enm and ang, I don't like that one bit. fr and en are more mutually intelligible then ang and en, and I don't see any use in labelling ang as en. Furthermore, if ang can validly be labeled en, it can also be validly labeled sco, adding another layer of complexity. Can la really be tagged as any Romance language? Can dum (Middle Dutch) be tagged as af (Afrikaans)? Can 17th century Dutch be tagged as af (Afrikaans)? > Inform proposers of such variants > that ISO 639-6 is currently being designed and if the need is not urgent > delay until ISO 639-6 is published. It's one thing to wait for ISO 639-3, which is clearly available in a late draft, but something that is "currently being designed" is not something I feel it's reasonable to expect people to wait for. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 14 08:07:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHJqm-00043q-Ji; Wed, 14 Feb 2007 08:07:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHJql-00040u-BV for ltru@ietf.org; Wed, 14 Feb 2007 08:07:07 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHJqi-0002bx-2Z for ltru@ietf.org; Wed, 14 Feb 2007 08:07:07 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 9E83926C22D; Wed, 14 Feb 2007 14:06:39 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id EB18C26C236; Wed, 14 Feb 2007 14:06:38 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id DCC8858ECE7; Wed, 14 Feb 2007 14:06:38 +0100 (CET) Date: Wed, 14 Feb 2007 14:06:38 +0100 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20070214130638.GA21542@nic.fr> References: <002501c75011$ad023e60$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002501c75011$ad023e60$6401a8c0@DGBP7M81> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: LTRU Working Group Subject: [Ltru] Re: "Placeholder" dates in draft Regsitry (was: Re: Progress) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Feb 14, 2007 at 12:25:24AM -0800, Doug Ewell wrote a message of 27 lines which said: > Does anyone else feel this would help? -1 It would break type checking systems (SQL database with CONSTRAINTS, XML with schemas, etc). _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 14 10:28:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHM34-0006ox-3O; Wed, 14 Feb 2007 10:27:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHM32-0006om-5p for ltru@ietf.org; Wed, 14 Feb 2007 10:27:56 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHM30-0002bq-R3 for ltru@ietf.org; Wed, 14 Feb 2007 10:27:56 -0500 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 14 Feb 2007 15:27:51 +0000 From: "Debbie Garside" To: Subject: RE: [Ltru] Re: Macrolanguages, countries & orthographies Date: Wed, 14 Feb 2007 15:27:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcdQOYniMBn3pXHbT/mTwGWuhiX5YAAEJFcQ In-Reply-To: <6d99d1fd0702140506u5c32e433q5dc92462066d465@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ietf-languages@iana.org, 'Lars Aronsson' , '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 Message-Id: David Starner wrote: > As a user of en, enm and ang, I don't like that one bit. fr > and en are more mutually intelligible then ang and en, and I > don't see any use in labelling ang as en. But I see people who are looking for a language subtag to denote Old English using English as a starting point in a hierarchical system such as ISO 639-6; makes sense to me. > Furthermore, if ang > can validly be labeled en, it can also be validly labeled > sco, adding another layer of complexity. I note Ethnologue have classified sco under English! But you are right, to be able to link languages by mutual intelligibility requires a multi-parent/child relationship system. That's not what I am advocating at the moment (emphasis on the word moment :-)). > It's one thing to wait for ISO 639-3, which is clearly > available in a late draft, but something that is "currently > being designed" is not something I feel it's reasonable to > expect people to wait for. We have waited some 5 years for ISO 639-3. I think for the last year people have been holding off on registration requests because of it. ISO 639-6 is due for publication in early 2008 but I don't think people should have to wait if their need is urgent; register variants via RFC4646. I have no problem with that. Best regards Debbie > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 14 11:21:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMsS-0001UV-VC; Wed, 14 Feb 2007 11:21:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMsR-0001U4-Du for ltru@ietf.org; Wed, 14 Feb 2007 11:21:03 -0500 Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHMsQ-0001CQ-4f for ltru@ietf.org; Wed, 14 Feb 2007 11:21:03 -0500 Received: (qmail 49582 messnum 2902371 invoked from network[194.125.174.59/ts09-059.dublin.indigo.ie]); 14 Feb 2007 16:21:00 -0000 Received: from ts09-059.dublin.indigo.ie (HELO ?194.125.174.59?) (194.125.174.59) by mail07.svc.cra.dublin.eircom.net (qp 49582) with SMTP; 14 Feb 2007 16:21:00 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <20070214130638.GA21542@nic.fr> References: <002501c75011$ad023e60$6401a8c0@DGBP7M81> <20070214130638.GA21542@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2711F304-8A45-4085-89C7-D176FDCBA55C@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: "Placeholder" dates in draft Regsitry (was: Re: Progress) Date: Wed, 14 Feb 2007 16:23:34 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) 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 Would such a placeholder as 6666-06-06, 7777-07-07 or 1111-11-11 =20 break such systems, Stephane?:-) A quick google for 2008-01-01 finds ten whole pages of events scheduled to = happen =20 on 2008-01-01, should we live so long. If you believe that it is not a problem for LTRU to declare =20 2008-01-01 a "fictitious" date for its own purposes, then I respect =20 your right to hold to that as a matter of principle I do not =20 understand, but I do not think that particular choice to be =20 intrinsically important and I do believe that a less ambiguous (more =20 obvious) placeholder would be less confusing (more help) to human =20 readers reviewing the text. mg On 14 Feb 2007, at 13:06, scr=EDobh Stephane Bortzmeyer: > On Wed, Feb 14, 2007 at 12:25:24AM -0800, > Doug Ewell wrote > a message of 27 lines which said: > >> Does anyone else feel this would help? >> > > -1 > > It would break type checking systems (SQL database with CONSTRAINTS, > XML with schemas, etc). - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 14 11:35:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHN6n-0001Nj-Fj; Wed, 14 Feb 2007 11:35:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHN6m-0001Ne-07 for ltru@ietf.org; Wed, 14 Feb 2007 11:35:52 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHN6j-0003zX-Hq for ltru@ietf.org; Wed, 14 Feb 2007 11:35:51 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HHN6j-0000Qh-3v; Wed, 14 Feb 2007 11:35:49 -0500 Date: Wed, 14 Feb 2007 11:35:49 -0500 To: Marion Gunn Subject: Re: [Ltru] Re: "Placeholder" dates in draft Regsitry (was: Re: Progress) Message-ID: <20070214163549.GD19053@mercury.ccil.org> References: <002501c75011$ad023e60$6401a8c0@DGBP7M81> <20070214130638.GA21542@nic.fr> <2711F304-8A45-4085-89C7-D176FDCBA55C@egt.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2711F304-8A45-4085-89C7-D176FDCBA55C@egt.ie> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Marion Gunn scripsit: > Would such a placeholder as 6666-06-06, 7777-07-07 or 1111-11-11 > break such systems, Stephane?:-) Unfortunately, dates later than 2038 are hard for many systems to handle. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Big as a house, much bigger than a house, it looked to [Sam], a grey-clad moving hill. Fear and wonder, maybe, enlarged him in the hobbit's eyes, but the Mumak of Harad was indeed a beast of vast bulk, and the like of him does not walk now in Middle-earth; his kin that live still in latter days are but memories of his girth and his majesty. --"Of Herbs and Stewed Rabbit" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 14 11:55:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHNPb-0004sy-GT; Wed, 14 Feb 2007 11:55:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHNPa-0004sj-Hv for ltru@ietf.org; Wed, 14 Feb 2007 11:55:18 -0500 Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHNPZ-0006kF-9q for ltru@ietf.org; Wed, 14 Feb 2007 11:55:18 -0500 Received: (qmail 78948 messnum 2906674 invoked from network[194.125.174.59/ts09-059.dublin.indigo.ie]); 14 Feb 2007 16:55:15 -0000 Received: from ts09-059.dublin.indigo.ie (HELO ?194.125.174.59?) (194.125.174.59) by mail07.svc.cra.dublin.eircom.net (qp 78948) with SMTP; 14 Feb 2007 16:55:15 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <20070214163549.GD19053@mercury.ccil.org> References: <002501c75011$ad023e60$6401a8c0@DGBP7M81> <20070214130638.GA21542@nic.fr> <2711F304-8A45-4085-89C7-D176FDCBA55C@egt.ie> <20070214163549.GD19053@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4CF8A066-519F-4978-97E1-12BC7FBF1E22@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: "Placeholder" dates in draft Regsitry (was: Re: Progress) Date: Wed, 14 Feb 2007 16:57:47 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org For some systems, yes - hence the inclusion of 1111-11-11. mg On 14 Feb 2007, at 16:35, scr=EDobh John Cowan: > Marion Gunn scripsit: > > >> Would such a placeholder as 6666-06-06, 7777-07-07 or 1111-11-11 >> break such systems, Stephane?:-) >> > > Unfortunately, dates later than 2038 are hard for many systems to > handle. - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 14 12:46:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOCS-0004pM-Ct; Wed, 14 Feb 2007 12:45:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOCR-0004pH-42 for ltru@ietf.org; Wed, 14 Feb 2007 12:45:47 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHOCP-00052x-Lf for ltru@ietf.org; Wed, 14 Feb 2007 12:45:47 -0500 Received: by ug-out-1314.google.com with SMTP id 72so281560ugd for ; Wed, 14 Feb 2007 09:45:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iHvExbyy9/hzBNuIDLSKHHQWfxWcnOMsCvrPbMghZXSs/Hbtz9b47D3lPmxtWw1Xelc6u4Tp1HxC9AxirGPsN/oDATmekFAVVOWl2uw7yA7cqaFVXRCzfnm9j36VEROKINqQ7DSx9pMT+DLcI+p4XoyRhOogrZs4bLoTtGQRW8o= Received: by 10.114.169.2 with SMTP id r2mr463257wae.1171475142736; Wed, 14 Feb 2007 09:45:42 -0800 (PST) Received: by 10.114.12.2 with HTTP; Wed, 14 Feb 2007 09:45:42 -0800 (PST) Message-ID: <6d99d1fd0702140945u38ba66s585b953d76ee7936@mail.gmail.com> Date: Wed, 14 Feb 2007 11:45:42 -0600 From: "David Starner" To: "Debbie Garside" Subject: Re: [Ltru] Re: Macrolanguages, countries & orthographies In-Reply-To: <45d32a7a.4fe73a0a.5c7e.ffff9179SMTPIN_ADDED@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6d99d1fd0702140506u5c32e433q5dc92462066d465@mail.gmail.com> <45d32a7a.4fe73a0a.5c7e.ffff9179SMTPIN_ADDED@mx.google.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ietf-languages@iana.org, Lars Aronsson , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 2/14/07, Debbie Garside wrote: > David Starner wrote: > > > As a user of en, enm and ang, I don't like that one bit. fr > > and en are more mutually intelligible then ang and en, and I > > don't see any use in labelling ang as en. > > But I see people who are looking for a language subtag to denote Old English > using English as a starting point in a hierarchical system such as ISO > 639-6; makes sense to me. > > > Furthermore, if ang > > can validly be labeled en, it can also be validly labeled > > sco, adding another layer of complexity. > > I note Ethnologue have classified sco under English! But you are right, to > be able to link languages by mutual intelligibility requires a > multi-parent/child relationship system. That's not what I am advocating at > the moment (emphasis on the word moment :-)). My comment had nothing to do with mutual intelligibility. There is no theoretic reason to prioritize English (en) over Scots (sco) as including ang and enm. They both descended from enm and ultimately ang. Likewise, there's no reason to prioritize modern Dutch over Afrikaans as covering Middle Dutch (dum); it is equally valid to consider Middle Dutch a historical form of one as the other. > We have waited some 5 years for ISO 639-3. I think for the last year people > have been holding off on registration requests because of it. ISO 639-6 is > due for publication in early 2008 but I don't think people should have to > wait if their need is urgent; register variants via RFC4646. I have no > problem with that. Until I can see the draft standard, I'm not going to worry about it. I'll hold off on ISO 639-3 only because I can have it in my hands right now. I don't think it's reasonable to expect people to hold off for a standard that's expected to be published in a year and that they can't check today to see if it fits their needs; I don't even know if ISO 639-6 is going to be considered suitable and useful for the language tagging RFC. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 14 12:48:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOFN-00075k-CP; Wed, 14 Feb 2007 12:48:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOFL-000716-Jl for ltru@ietf.org; Wed, 14 Feb 2007 12:48:47 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHOFK-0005VN-9u for ltru@ietf.org; Wed, 14 Feb 2007 12:48:47 -0500 Received: from [172.21.148.97] (wlanvpn-mc2e-246-97.corp.yahoo.com [172.21.148.97]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l1EHmVsf041211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 09:48:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=lAU3lsE1jx+JynNTOAduTzS6bNvtJjrQkLMDjo8NDHqGK6EPJn5rf96jY0PkAt81 Message-ID: <45D34B6E.8040807@yahoo-inc.com> Date: Wed, 14 Feb 2007 09:48:30 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Marion Gunn Subject: Re: [Ltru] Re: "Placeholder" dates in draft Regsitry References: <002501c75011$ad023e60$6401a8c0@DGBP7M81> <20070214130638.GA21542@nic.fr> <2711F304-8A45-4085-89C7-D176FDCBA55C@egt.ie> <20070214163549.GD19053@mercury.ccil.org> <4CF8A066-519F-4978-97E1-12BC7FBF1E22@egt.ie> In-Reply-To: <4CF8A066-519F-4978-97E1-12BC7FBF1E22@egt.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.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 1. This is only a temporary problem: it goes away when we get to publication. 2. Doug's original solution is sufficient. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 14 13:30:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOtJ-00046P-Tg; Wed, 14 Feb 2007 13:30:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOtI-00045t-0L for ltru@ietf.org; Wed, 14 Feb 2007 13:30:04 -0500 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HHOtE-0006pC-Km for ltru@ietf.org; Wed, 14 Feb 2007 13:30:03 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 14 Feb 2007 10:29:57 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Wed, 14 Feb 2007 10:29:57 -0800 From: Peter Constable To: "ietf-languages@iana.org" , 'LTRU Working Group' Date: Wed, 14 Feb 2007 10:29:54 -0800 Subject: RE: [Ltru] Re: Macrolanguages, countries & orthographies Thread-Topic: [Ltru] Re: Macrolanguages, countries & orthographies Thread-Index: AcdQOYniMBn3pXHbT/mTwGWuhiX5YAAEJFcQAAazsIA= Message-ID: References: <6d99d1fd0702140506u5c32e433q5dc92462066d465@mail.gmail.com> 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: 7655788c23eb79e336f5f8ba8bce7906 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: Debbie Garside [mailto:debbie@ictmarketing.co.uk] >> As a user of en, enm and ang, I don't like that one bit. fr >> and en are more mutually intelligible then ang and en, and I >> don't see any use in labelling ang as en. > > But I see people who are looking for a language subtag to denote > Old English using English as a starting point in a hierarchical > system such as ISO 639-6; makes sense to me. It's by no means obvious to me that it makes sense. That's using the ID tha= t has very widely been associated with the modern language as the root for = some extended set of historical connections of unclear scope. David has cle= arly demonstrated how that can lead to an absolute mess. If anything is app= ropriate as the root of some historical hierarchy, it is a protolanguage, o= r the concept of a collection based on historical ("genetic") associations.= IDs for collection exist and capture such concepts. If you really want a h= ierarchy, something along the lines of Indo-European/Germanic/Middle-Englis= h might makes sense. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 14 16:17:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHRV7-0004yL-Bp; Wed, 14 Feb 2007 16:17:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHRV6-0004y2-MJ for ltru@ietf.org; Wed, 14 Feb 2007 16:17:16 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHRV5-0004y6-8X for ltru@ietf.org; Wed, 14 Feb 2007 16:17:16 -0500 Received: from DebbieLaptop ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 14 Feb 2007 21:17:12 +0000 From: "Debbie Garside" To: , , "'LTRU Working Group'" Subject: RE: [Ltru] Re: Macrolanguages, countries & orthographies Date: Wed, 14 Feb 2007 21:17:01 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcdQOYniMBn3pXHbT/mTwGWuhiX5YAAEJFcQAAazsIAAA17RAA== In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Message-Id: IMHO, the hierarchy should look something like this (missing a few bits out): Indo-European - Germanic -- West Germanic --- Anglo-Frisian/North Sea Germanic ---- Anglic ----- Olde English/Anglo Saxon ----- Middle English ------ Early Northern Middle English ------- Early Scots Northern Middle English -------- Middle Scots --------- Modern Scots ------ Early Southern and S Western Middle English ------ Early Midland and S Eastern Middle English ------- Early Modern English -------- Modern Standard English Has the ISO 639 ID been used specifically for just modern? How have people tagged early scots? sco? Historically (in language tagging terms) has en always been used for modern? I am not saying you are wrong, but decisions need to be made wrt these issues. Do all ISO 639-1/2/3 ID's represent the modern language (written and spoken or just written?) unless historic is specifically stated? Questions questions questions... A veritable can of worms. Best regards Debbie > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: 14 February 2007 18:30 > To: ietf-languages@iana.org; 'LTRU Working Group' > Subject: RE: [Ltru] Re: Macrolanguages, countries & orthographies > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > >> As a user of en, enm and ang, I don't like that one bit. fr and en > >> are more mutually intelligible then ang and en, and I > don't see any > >> use in labelling ang as en. > > > > But I see people who are looking for a language subtag to > denote Old > > English using English as a starting point in a hierarchical system > > such as ISO 639-6; makes sense to me. > > It's by no means obvious to me that it makes sense. That's > using the ID that has very widely been associated with the > modern language as the root for some extended set of > historical connections of unclear scope. David has clearly > demonstrated how that can lead to an absolute mess. If > anything is appropriate as the root of some historical > hierarchy, it is a protolanguage, or the concept of a > collection based on historical ("genetic") associations. IDs > for collection exist and capture such concepts. If you really > want a hierarchy, something along the lines of > Indo-European/Germanic/Middle-English might makes sense. > > > > 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 Thu Feb 15 01:57:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHaZ0-0005mJ-18; Thu, 15 Feb 2007 01:57:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHaYx-0005m1-CQ; Thu, 15 Feb 2007 01:57:51 -0500 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHaYv-0006xR-SZ; Thu, 15 Feb 2007 01:57:51 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Iu63Q30jS4RQLeQqAICrQVOy8DZVCiNgxrVZ61tckc5VjYWe+ArY1pc+tCidfl2g; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HHaYp-0005he-AL; Thu, 15 Feb 2007 01:57:43 -0500 Received: from 222.255.118.210 by webmail.atl.earthlink.net with HTTP; Thu, 15 Feb 2007 01:57:43 -0500 Message-ID: <18419027.1171522663369.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Thu, 15 Feb 2007 13:57:43 +0700 (GMT+07:00) From: Randy Presuhn To: ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882c120543388a5fd78e329a15e9524559e8a6d58d0634061d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.26 X-Spam-Score: 1.1 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ietf-languages@iana.org, ltru@ietf.org Subject: [Ltru] RE: Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) to Proposed Standard X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: 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: "McDonald, Ira" >Sent: Feb 11, 2007 4:15 AM >To: 'John Cowan' , Doug Ewell >Cc: ietf-languages@iana.org, LTRU Working Group , ietf@ietf.org >Subject: RE: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Ta g MIB) to Proposed Standard > >Hi, > >Right - ASN.1 doesn't allow discontinuous integer ranges. ... No. In a SIZE qualifier, a discontiguous range is perfectly legal ASN.1 There are examples of this in RFC 2579, among others. In this particular case, something like SYNTAX OCTET STRING (SIZE (0 | 2..60)) (replacing 60 with whatever the consensus upper bound should be) would seem appropriate. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Feb 15 07:00:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHfHR-0006Ud-Al; Thu, 15 Feb 2007 07:00:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHfHQ-0006UY-6T for ltru@ietf.org; Thu, 15 Feb 2007 07:00:04 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHfHN-0002ZY-Tq for ltru@ietf.org; Thu, 15 Feb 2007 07:00:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 8AA5C26C276; Thu, 15 Feb 2007 13:00:01 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id CCBEC26C262; Thu, 15 Feb 2007 12:59:58 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id C8B3758E9F0; Thu, 15 Feb 2007 12:59:58 +0100 (CET) Date: Thu, 15 Feb 2007 12:59:58 +0100 From: Stephane Bortzmeyer To: John Cowan Message-ID: <20070215115958.GA1448@nic.fr> References: <002501c75011$ad023e60$6401a8c0@DGBP7M81> <20070214130638.GA21542@nic.fr> <2711F304-8A45-4085-89C7-D176FDCBA55C@egt.ie> <20070214163549.GD19053@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070214163549.GD19053@mercury.ccil.org> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.6 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: LTRU Working Group Subject: [Ltru] Re: "Placeholder" dates in draft Regsitry (was: Re: Progress) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Feb 14, 2007 at 11:35:49AM -0500, John Cowan wrote a message of 20 lines which said: > > Would such a placeholder as 6666-06-06, 7777-07-07 or 1111-11-11 > > break such systems, Stephane?:-) > > Unfortunately, dates later than 2038 are hard for many systems to > handle. My favorite DBMS, PostgreSQL, can do it :-) essais=> CREATE TABLE Events (id SERIAL, name TEXT, date DATE); NOTICE: CREATE TABLE will create implicit sequence "events_id_seq" for "serial" column "events.id" CREATE TABLE essais=> INSERT INTO Events (name, date) VALUES ('Foo', '2150-06-03'); INSERT 5346177 1 essais=> INSERT INTO Events (name, date) VALUES ('Bar', '3210-12-29'); INSERT 5346178 1 essais=> SELECT * FROM Events ORDER BY date; id | name | date ----+------+------------ 1 | Foo | 2150-06-03 2 | Bar | 3210-12-29 (2 rows) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Feb 15 07:35:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHfpS-0006qu-Fp; Thu, 15 Feb 2007 07:35:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHfpQ-0006qB-OP; Thu, 15 Feb 2007 07:35:12 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHfpP-0007Ep-GC; Thu, 15 Feb 2007 07:35:12 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l1FCZAJp027558; Thu, 15 Feb 2007 07:35:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Feb 2007 14:35:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) toProposed Standard Thread-Index: AcdQpU0q3iUod60UTSeIHhO9tKN32gAWFQnA References: <20070210110002.CA2702596E8@eikenes.alvestrand.no><005301c74d3c$0bb00510$6801a8c0@DGBP7M81> <20070210181535.GN30294@mercury.ccil.org> From: "Romascanu, Dan \(Dan\)" To: "John Cowan" , "Doug Ewell" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ietf-languages@iana.org, LTRU Working Group , ietf@ietf.org Subject: [Ltru] RE: Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) toProposed 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 =20 =20 > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org]=20 > >=20 > > SYNTAX OCTET STRING (SIZE (0..60)) > >=20 > > be amended to exclude the 1-character case. I assume that a=20 > > zero-length tag, while also not defined in RFC 4646, was=20 > included in=20 > > the I-D to allow the special case of "no tag." >=20 > AFAIK, ASN.1 does not allow sizes like (0, 2..60). I=20 > wouldn't even bother with this change. >=20 Actually (SIZE (0 | 2..60)) is allowed and would match this case.=20 Dan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Feb 15 10:21:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHiQP-0001dV-Pu; Thu, 15 Feb 2007 10:21:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHiQO-0001WP-TH for ltru@ietf.org; Thu, 15 Feb 2007 10:21:32 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHiQL-0006Nf-1A for ltru@ietf.org; Thu, 15 Feb 2007 10:21:32 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HHiQB-000405-UP; Thu, 15 Feb 2007 10:21:20 -0500 Date: Thu, 15 Feb 2007 10:21:19 -0500 To: Peter Constable Subject: Re: [Ltru] Re: Macrolanguages, countries & orthographies Message-ID: <20070215152119.GA27160@mercury.ccil.org> References: <200702141827.l1EIRrxF022339@pechora1.icann.org> <20070214223213.GA8284@mercury.ccil.org> 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: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > From: John Cowan [mailto:cowan@ccil.org] > > > But I, at least, am certainly not proposing making en/eng > > into a macrolanguage. A macrolanguage covering ang, mne, > > eng, and sco, yes. > > Go back and read the description of "macrolanguage" and tell me in > what context that would apply to all of these? When is it useful to > treat all of these as a single language? When you are dealing with texts that are close to the boundaries of any pair (okay, not sco/ang or eng/ang, I admit, but there are other macrolanguages like that already). -- I suggest you call for help, John Cowan or learn the difficult art of mud-breathing. cowan@ccil.org --Great-Souled Sam http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Feb 15 11:56:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHjtO-00026d-0c; Thu, 15 Feb 2007 11:55:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHjtM-00026S-Ky for ltru@ietf.org; Thu, 15 Feb 2007 11:55:32 -0500 Received: from wr-out-0506.google.com ([64.233.184.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHjtH-0002qJ-1J for ltru@ietf.org; Thu, 15 Feb 2007 11:55:32 -0500 Received: by wr-out-0506.google.com with SMTP id 67so1096414wri for ; Thu, 15 Feb 2007 08:55:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=luTBbqqHl1e1o7AnYadGr4v0BGWQUKr1FWJr3M/MFIzvcobZSoOeC+HloBhveMjpM/Xi563o5HxawQTsGIAS7XD47qSYhb0yoLt28Lk2xnfxJWLLPSeybf4y9d3xJKAHr0TlM0z2pod4KGihbEvcTLh3O8PZ/B3dJvRcvK8Rj8o= Received: by 10.90.52.18 with SMTP id z18mr2707432agz.1171558526312; Thu, 15 Feb 2007 08:55:26 -0800 (PST) Received: by 10.90.50.20 with HTTP; Thu, 15 Feb 2007 08:55:26 -0800 (PST) Message-ID: <30b660a20702150855r11fff871se2cddb412f87169e@mail.gmail.com> Date: Thu, 15 Feb 2007 08:55:26 -0800 From: "Mark Davis" To: "Anthony Aristar" In-Reply-To: <20070215082323.hiiu4xvtes8wogww@webmail0.linguistlist.org> MIME-Version: 1.0 References: <20070215082323.hiiu4xvtes8wogww@webmail0.linguistlist.org> X-Google-Sender-Auth: 87c71eb77125df54 X-Spam-Score: 0.5 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: LTRU Working Group , ietf-languages@alvestrand.no Subject: [Ltru] Re: Ietf-languages Digest, Vol 50, Issue 15 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1364567260==" Errors-To: ltru-bounces@ietf.org --===============1364567260== Content-Type: multipart/alternative; boundary="----=_Part_21983_18069180.1171558526177" ------=_Part_21983_18069180.1171558526177 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline WW91ciBxdW90YXRpb24gYmVsb3cgb21pdHMgdGhlIHRydWUgYXV0aG9yLCBhbmQgbWF5IGxlYXZl IHRoZSBpbXByZXNzaW9uCnRoYXQgSSB3cm90ZSBhIG51bWJlciBvZiBwYXJhZ3JhcGhzIHRoYXQg SSBkbyBub3QgYWdyZWUgd2l0aCBhbmQgZGlkIG5vdAp3cml0ZS4gSSBvbmx5IHdyb3RlICJBc3N1 bWUgdGhhdCBvbGQgQ3plY2ggLi4uIiAtLSBzb21lb25lIGVsc2Ugd3JvdGUgdGhlCiJCdXQgaXMg dGhpcyBhIHJlYWwgcHJvYmxlbS4uLi4iCgo+IE1hcmsgRGF2aXMgd3JvdGU6Cj4KPiA+IEFzc3Vt ZSB0aGF0IG9sZCBDemVjaCBpcyBhcyBkaWZmZXJlbnQgZnJvbSBtb2Rlcm4gYXMgZnJvIGlzIGZy b20gZnIuCj4KPiBCdXQgaXMgdGhpcyBhIHJlYWwgcHJvYmxlbT8gIEhvdyBtdWNoIHRvdGFsIGxp dGVyYXR1cmUgaXMgd3JpdHRlbgouLi4KClRoYXQgYmVpbmcgc2FpZCwgdGhlcmUgYXJlIHR3byBt b2RlbHMgdGhhdCBJU08gY291bGQgYmUgdXNpbmcuCgogICAxLiBPdmVybGFwcGluZy4gJ2VuZycg bWVhbnMgYW55IEVuZ2xpc2gsIG1vZGVybiBvciBoaXN0b3JpYy4gJ2FuZycKICAgbWVhbnMgc3Bl Y2lmaWNhbGx5IE9sZCBFbmdsaXNoLCBhIHN1YnNldCBvZiAnZW5nJy4gJ2NlcycgbWVhbnMgYW55 IEN6ZWNoLgogICBUaGVyZSBpcyBubyB0YWcgc3BlY2lmaWNhbGx5IGZvciBPbGQgQ3plY2guCiAg IDEuIHNvIEkgY291bGQgdGFnIEJlb3d1bGYgd2l0aCAnYW5nJyBvciAnZW5nJywgYnV0IFNoYWtl c3BlYXJlLAogICAgICBBdXN0ZW4sIGFuZCBSb2JpbiBXaWxsaWFtcyBvbmx5IHdpdGggJ2VuZycu CiAgICAgIDIuIFNtaWwgRmxhxaFrYSB6IFBhcmR1YmljIGFuZCBWw6FjbGF2IEhhdmVsIGFyZSBi b3RoIHRhZ2dlZCB3aXRoCiAgICAgICdjZXMnLgogICAgICAzLiBSZXF1ZXN0cyBmb3IgQkNQIDQ3 IHZhcmlhbnQgdGFncyBmb3IgU2hha2VzcGVhcmVhbiBFbmdsaXNoCiAgICAgIChlbi1TSEFLRVNQ Uikgb3Igb2xkIEN6ZWNoIChjcy1PTERDWkVDSCkgd291bGQgYmUgbGVnaXRpbWF0ZS4KICAgICAg NC4gQSByZXF1ZXN0IGZvciBhIHZhcmlhbnQgdGFnIGZvciBvbmx5IG1vZGVybiBFbmdsaXNoCiAg ICAgIChlbi1NT0RFTkdMKSwgdGh1cyBleGNsdWRpbmcgT2xkIEVuZ2xpc2gsIHdvdWxkIGJlIGxl Z2l0aW1hdGUuCiAgICAgIDIuIERpc2pvaW50LiAnZW5nJyBtZWFucyBvbmx5IG1vZGVybiBFbmds aXNoLCAnYW5nJyBtZWFucyBPbGQKICAgRW5nbGlzaCwgJ2NlcycgbWVhbnMgb25seSBtb2Rlcm4g Q3plY2guIFRoZXJlIGlzIG5vIHRhZyBhdCBhbGwgKGN1cnJlbnRseSkKICAgZm9yIE9sZCBDemVj aC4KICAgICAgMS4gc28gSSBjb3VsZCB0YWcgQmVvd3VsZiB3aXRoICdhbmcnIG9ubHkuCiAgICAg IDIuIGFuZCB0aGVyZSBpcyBubyB2YWxpZCBjdXJyZW50IGNvZGUgZm9yIHRhZ2dpbmcgZm9yIFNt aWwKICAgICAgRmxhxaFrYSB6IFBhcmR1YmljCiAgICAgIDMuIEEgcmVxdWVzdCBmb3IgQkNQIDQ3 IHZhcmlhbnQgdGFncyBmb3IgU2hha2VzcGVhcmVhbiBFbmdsaXNoCiAgICAgIChlbi1TSEFLRVNQ Uikgd291bGQgYmUgbGVnaXRpbWF0ZQogICAgICA0LiBBIHJlcXVlc3QgZm9yIGEgcmVnaXN0ZXJl ZCBvbGQgQ3plY2ggbGFuZ3VhZ2UgdGFnIChvbGRjemVjaCkKICAgICAgd291bGQgYmUgbGVnaXRp bWF0ZS4gKEhvd2V2ZXIgInByaW1hcnkgbGFuZ3VhZ2VzIGFyZSBzdHJvbmdseQogICAgICBSRUNP TU1FTkRFRCBmb3IgcmVnaXN0cmF0aW9uIHdpdGggSVNPIDYzOSwgYW5kIHByb3Bvc2FscyByZWpl Y3RlZCBieSBJU08KICAgICAgNjM5L1JBIHdpbGwgYmUgY2xvc2VseSBzY3J1dGluaXplZCBiZWZv cmUgdGhleSBhcmUgcmVnaXN0ZXJlZCB3aXRoIElBTkEuIgogICAgICApCgpJIGRvbid0IHRoaW5r IHRoZXkgYXJlIHVzaW5nIG1vZGVsIG51bWJlciBvbmUsIGJ1dCB3ZSBuZWVkIHRvIGZpbmQgb3V0 LgoKTWFyawoKT24gMi8xNS8wNywgQW50aG9ueSBBcmlzdGFyIDxhcmlzdGFyQGxpbmd1aXN0bGlz dC5vcmc+IHdyb3RlOgo+Cj4gV2l0aCBhbGwgZHVlIHJlc3BlY3QsIHRoaXMgc2VlbXMgbGlrZSBh IHZlcnkgb2RkIGRpc2N1c3Npb24gZnJvbSBteQo+IHBlcnNwZWN0aXZlICBhcyBhIGxpbmd1aXN0 aWNzIHByb2Zlc3Nvci4gIFRoZSBkaXNjdXNzaW9uIHNlZW1zIHRvCj4gcHJlc3VwcG9zZSB0aGF0 IGFsbCB0aGF0IG1hdHRlcnMgaXMgd2hldGhlciBNaWNyb3NvZnQgaXMgZ29pbmcgdG8gb25lCj4g ZGF5IHByb2R1Y2UgYSB2ZXJzaW9uIG9mIFdvcmQgaW4gTWlkZGxlIEhpZ2ggR2VybWFuIG9yIE9s ZCBFbmdsaXNoLCBvcgo+IGhvdyBtYW55IHRleHRzIGV4aXN0IGluIGEgbGFuZ3VhZ2UuCj4KPiBC dXQgdGhlIElTTyA2MzkgY29kZXMgYXJlIHVzZWQgZm9yIG11Y2ggbW9yZSB0aGFuIHRoaXMuICBJ biBwYXJ0aWN1bGFyLAo+IHRoZXkgYXJlIHVzZWQgdG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHks IGFsbG93aW5nIG1hdGVyaWFsIG9mIHRoZSBzYW1lCj4gbGluZ3Vpc3RpYyBuYXR1cmUgdG8gYmUg Zm91bmQgaW4gc2VhcmNoZXMsIGFuZCB0byBiZSBjb21wYXJlZCB1c2luZyB0aGUKPiBsaW5ndWlz dGljIG9udG9sb2dpZXMgdGhhdCBhcmUgbm93IGJlaW5nIGRldmVsb3BlZC4gIElmIEkgYW0gYSBz Y2hvbGFyCj4gc2VhcmNoaW5nIGZvciB0ZXh0cyBpbiBPbGQgRW5nbGlzaCAob3IgT2xkIEhpZ2gg R2VybWFuLCBmb3IgdGhhdAo+IG1hdHRlcikgYW5kIGV2ZXJ5b25lIGhhcyBiZWVuIGNhdmFsaWVy IGVub3VnaCB0byBjb2RlIHN1Y2ggbWF0ZXJpYWwKPiB3aXRoIGVuZyBhbmQgZGV1LCB3aGF0IHRo ZSBzZWFyY2ggZW5naW5lcyByZXR1cm4gd2lsbCBiZSB1dHRlcmx5Cj4gdXNlbGVzcyB0byBtZS4g IEkgYW0gZ29pbmcgdG8gYmUgZmxvb2RlZCB3aXRoIHN1Y2ggYSBxdWFudGl0eSBvZgo+IG1hdGVy aWFsIGluIE1vZGVybiBFbmdsaXNoIGFuZCBNb2Rlcm4gR2VybWFuIHRoYXQgc2VhcmNoaW5nIHRo cm91Z2ggaXQKPiB3aWxsIGJlIGVzc2VudGlhbGx5IGltcG9zc2libGUuCj4KPiBTbyBpZiB5b3Ug cmVhbGx5IGJlbGlldmUgdGhhdCBpdCBkb2Vzbid0IG1hdHRlciBpZiB5b3UgY29kZSBFbmdsaXNo Cj4gbWF0ZXJpYWwgYXMgZW5nLCB3aGF0ZXZlciBpdHMgcGVyaW9kLCB3aGF0IHlvdSdyZSByZWFs bHkgc2F5aW5nIGlzIHRoYXQKPiB5b3UgZG9uJ3QgcmVhbGx5IGNhcmUgYWJvdXQgaW50ZXJvcGVy YWJpbGl0eSwgYW5kIHRoYXQgeW91IGRvbid0IHJlYWxseQo+IGNhcmUgYWJvdXQgc2Nob2xhcnNo aXAuCj4KPiAgICAgICAgICAgICAgICAgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioKPiBBbnRob255IEFyaXN0YXIsIERpcmVjdG9yLCBJbnN0aXR1dGUgZm9yIExhbmd1YWdl IEluZm9ybWF0aW9uICYgVGVjaG5vbG9neQo+ICAgICAgICAgICAgICAgICAgICBQcm9mZXNzb3Ig b2YgTGluZ3Vpc3RpY3MKPiBNb2RlcmF0b3IsIExJTkdVSVNUICAgICAgICAgICAgICAgUHJpbmNp cGFsIEludmVzdGlnYXRvciwgRU1FTEQgUHJvamVjdAo+IExpbmd1aXN0aWNzIFByb2dyYW0KPiBE ZXB0LiBvZiBFbmdsaXNoICAgICAgICAgICAgICAgICAgYXJpc3RhckBsaW5ndWlzdGxpc3Qub3Jn Cj4gRWFzdGVybiBNaWNoaWdhbiBVbml2ZXJzaXR5ICAgICAgICAgICAgMjAwMCBIdXJvbiBSaXZl ciBEciwgU3VpdGUgMTA0Cj4gWXBzaWxhbnRpLCBNSSA0ODE5Nwo+IFUuUy5BLgo+Cj4gVVJMOiBo dHRwOi8vbGluZ3Vpc3RsaXN0Lm9yZy9hcmlzdGFyLwo+ICAgICAgICAgICAgICAgICAqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo+Cj4gPiBNYXJrIERhdmlzIHdyb3RlOgo+ ID4KPiA+ID4gQXNzdW1lIHRoYXQgb2xkIEN6ZWNoIGlzIGFzIGRpZmZlcmVudCBmcm9tIG1vZGVy biBhcyBmcm8gaXMgZnJvbSBmci4KPiA+Cj4gPiBCdXQgaXMgdGhpcyBhIHJlYWwgcHJvYmxlbT8g IEhvdyBtdWNoIHRvdGFsIGxpdGVyYXR1cmUgaXMgd3JpdHRlbgo+ID4gYW5kIGF2YWlsYWJsZSBp biBkaWZmZXJlbnQgdmFyaWF0aW9ucyBvZiBDemVjaD8gIE15IHByZWp1ZGljZSBzYXlzCj4gPiB0 aGF0IGFzIGEgbmF0aW9uIHdpdGggYSBsYW5ndWFnZSBhbmQgbGl0ZXJhdHVyZSBvZiBpdHMgb3du LCBDemVjaAo+ID4gaXMgYWJvdXQgYXMgeW91bmcgYXMgRmlubmlzaCwgTm9yd2VnaWFuIG9yIFNl cmJpYW4sIGkuZS4gMTl0aAo+ID4gY2VudHVyeS4gIENhbiB5b3UgZ2l2ZSBhbnkgY29uY3JldGUg ZXhhbXBsZXMgd2hlbiBub3QgaGF2aW5nIGEKPiA+IHNlcGFyYXRlICpjb2RlKiBmb3IgcHJlLXJl bmFpc3NhbmNlIEN6ZWNoIGlzIGEgcHJhY3RpY2FsIHByb2JsZW0/Cj4gPgo+ID4gTGluZ3Vpc3Rz IG9mIGNvdXJzZSBoYXZlICpuYW1lcyogZm9yIFN3ZWRpc2ggb2YgYWxsIGFnZXMsIGJ1dCBJCj4g PiBzZWUgbm8gcmVhbCB1c2UgZm9yIGhhdmluZyBJU08gb3IgdGhlIElFVEYgc3BlY2lmeSBsYW5n dWFnZQo+ID4gKmNvZGVzKi4gIEkgY291bGQgYmUgd3JvbmcsIGJ1dCBpZiBzbyBwbGVhc2UgZW5s aWdodGVuIGFuZCBjb3JyZWN0Cj4gPiBtZS4gIE5vYm9keSBpcyBnb2luZyB0byB0cmFuc2xhdGUg T3Blbk9mZmljZSBvciBNb3ppbGxhIHRvIHRoZQo+ID4gbGFuZ3VhZ2Ugc3Bva2VuIGJ5IHZpa2lu Z3MgKE9sZCBOb3JzZSkgb3IgdGhlIFN3ZWRpc2ggdXNlZCBkdXJpbmcKPiA+IHRoZSBMdXRoZXJh biByZWZvcm1hdGlvbiAoY2FsbGVkIE5ldyBTd2VkaXNoLCBpcm9uaWNhbGx5KS4KPiA+Cj4gPiBZ ZXMsIHRoZXJlIGlzIG5vdyBhIGJyYW5jaCBvZiBXaWtpcGVkaWEgaW4gT2xkIEVuZ2xpc2gKPiA+ IChhbmcud2lraXBlZGlhLm9yZyksIGJ1dCB0aGF0IGlzIGEgcmFyZSBleGNlcHRpb24uICBJIGRv bid0IGV4cGVjdAo+ID4gdGhpcyB0byBoYXBwZW4gaW4gb3RoZXIgbGFuZ3VhZ2VzLiAgQW5nIGhh cyBub3cgNzQ0IGFydGljbGVzLAo+ID4gY29tcGFyZWQgdG8gdGhlIDExLDAwMCBhcnRpY2xlcyBv ZiB0aGUgTGF0aW4gV2lraXBlZGlhLgo+Cj4KPgo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwo+IElldGYtbGFuZ3VhZ2VzIG1haWxpbmcgbGlzdAo+ IElldGYtbGFuZ3VhZ2VzQGFsdmVzdHJhbmQubm8KPiBodHRwOi8vd3d3LmFsdmVzdHJhbmQubm8v bWFpbG1hbi9saXN0aW5mby9pZXRmLWxhbmd1YWdlcwo+CgoKCi0tIApNYXJrCg== ------=_Part_21983_18069180.1171558526177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline WW91ciBxdW90YXRpb24gYmVsb3cgb21pdHMgdGhlIHRydWUgYXV0aG9yLCBhbmQgbWF5IGxlYXZl IHRoZSBpbXByZXNzaW9uIHRoYXQgSSB3cm90ZSBhIG51bWJlciBvZiBwYXJhZ3JhcGhzIHRoYXQg SSBkbyBub3QgYWdyZWUgd2l0aCBhbmQgZGlkIG5vdCB3cml0ZS4gSSBvbmx5IHdyb3RlICZxdW90 O0Fzc3VtZSB0aGF0IG9sZCBDemVjaCAuLi4mcXVvdDsgLS0gc29tZW9uZSBlbHNlIHdyb3RlIHRo ZSAmcXVvdDtCdXQgaXMgdGhpcyBhIHJlYWwgcHJvYmxlbS4uLi4mcXVvdDsgCjxicj48YnI+Jmd0 OyBNYXJrIERhdmlzIHdyb3RlOjxicj4mZ3Q7PGJyPiZndDsgJmd0OyBBc3N1bWUgdGhhdCBvbGQg Q3plY2ggaXMgYXMgZGlmZmVyZW50IGZyb20gbW9kZXJuIGFzIGZybyBpcyBmcm9tIGZyLjxicj4m Z3Q7PGJyPiZndDsgQnV0IGlzIHRoaXMgYSByZWFsIHByb2JsZW0/Jm5ic3A7Jm5ic3A7SG93IG11 Y2ggdG90YWwgbGl0ZXJhdHVyZSBpcyB3cml0dGVuPGJyPi4uLjxicj48YnI+VGhhdCBiZWluZyBz YWlkLCB0aGVyZSBhcmUgdHdvIG1vZGVscyB0aGF0IElTTyBjb3VsZCBiZSB1c2luZy4KPGJyPjxv bD48bGk+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+T3ZlcmxhcHBpbmcuIDwvc3Bh bj4mIzM5O2VuZyYjMzk7IG1lYW5zIGFueSBFbmdsaXNoLCBtb2Rlcm4gb3IgaGlzdG9yaWMuICYj Mzk7YW5nJiMzOTsgbWVhbnMgc3BlY2lmaWNhbGx5IE9sZCBFbmdsaXNoLCBhIHN1YnNldCBvZiAm IzM5O2VuZyYjMzk7LiAmIzM5O2NlcyYjMzk7IG1lYW5zIGFueSBDemVjaC4gVGhlcmUgaXMgbm8g dGFnIHNwZWNpZmljYWxseSBmb3IgT2xkIEN6ZWNoLgo8YnI+PC9saT48b2w+PGxpPnNvIEkgY291 bGQgdGFnIEJlb3d1bGYgd2l0aCAmIzM5O2FuZyYjMzk7IG9yICYjMzk7ZW5nJiMzOTssIGJ1dCBT aGFrZXNwZWFyZSwgQXVzdGVuLCBhbmQgUm9iaW4gV2lsbGlhbXMgb25seSB3aXRoICYjMzk7ZW5n JiMzOTsuPC9saT48bGk+U21pbCBGbGHFoWthIHogUGFyZHViaWMgYW5kIFbDoWNsYXYgSGF2ZWwg YXJlIGJvdGggdGFnZ2VkIHdpdGggJiMzOTtjZXMmIzM5Oy4KPC9saT48bGk+UmVxdWVzdHMgZm9y IEJDUCA0NyB2YXJpYW50IHRhZ3MgZm9yIFNoYWtlc3BlYXJlYW4gRW5nbGlzaCAoZW4tU0hBS0VT UFIpIG9yIG9sZCBDemVjaCAoY3MtT0xEQ1pFQ0gpIHdvdWxkIGJlIGxlZ2l0aW1hdGUuPC9saT48 bGk+QSByZXF1ZXN0IGZvciBhIHZhcmlhbnQgdGFnIGZvciBvbmx5IG1vZGVybiBFbmdsaXNoIChl bi1NT0RFTkdMKSwgdGh1cyBleGNsdWRpbmcgT2xkIEVuZ2xpc2gsIHdvdWxkIGJlIGxlZ2l0aW1h dGUuCjxicj48L2xpPjxzcGFuPjwvc3Bhbj48L29sPjxsaT48c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6IGJvbGQ7Ij5EaXNqb2ludC4gPC9zcGFuPiYjMzk7ZW5nJiMzOTsgbWVhbnMgb25seSBtb2Rl cm4gRW5nbGlzaCwgJiMzOTthbmcmIzM5OyBtZWFucyBPbGQgRW5nbGlzaCwgJiMzOTtjZXMmIzM5 OyBtZWFucyBvbmx5IG1vZGVybiBDemVjaC4gVGhlcmUgaXMgbm8gdGFnIGF0IGFsbCAoY3VycmVu dGx5KSBmb3IgT2xkIEN6ZWNoLgo8L2xpPjxvbD48bGk+c28gSSBjb3VsZCB0YWcgQmVvd3VsZiB3 aXRoICYjMzk7YW5nJiMzOTsgb25seS48L2xpPjxsaT5hbmQgdGhlcmUgaXMgbm8gdmFsaWQgY3Vy cmVudCBjb2RlIGZvciB0YWdnaW5nIGZvciA8c3Bhbj5TbWlsIEZsYcWha2EgeiBQYXJkdWJpYzwv c3Bhbj48L2xpPjxsaT5BIHJlcXVlc3QgZm9yIEJDUCA0NyB2YXJpYW50IHRhZ3MgZm9yIFNoYWtl c3BlYXJlYW4gRW5nbGlzaCAoZW4tU0hBS0VTUFIpIHdvdWxkIGJlIGxlZ2l0aW1hdGUKPC9saT48 bGk+QSByZXF1ZXN0IGZvciBhIHJlZ2lzdGVyZWQgb2xkIEN6ZWNoIGxhbmd1YWdlIHRhZyAob2xk Y3plY2gpIHdvdWxkIGJlIGxlZ2l0aW1hdGUuIDxzcGFuPihIb3dldmVyICZxdW90O3ByaW1hcnkg bGFuZ3VhZ2VzIGFyZSBzdHJvbmdseSBSRUNPTU1FTkRFRCBmb3IgcmVnaXN0cmF0aW9uIHdpdGgg SVNPIDYzOSwgYW5kIHByb3Bvc2FscyByZWplY3RlZCBieSBJU08gNjM5L1JBIHdpbGwgYmUgY2xv c2VseSBzY3J1dGluaXplZCBiZWZvcmUgdGhleSBhcmUgcmVnaXN0ZXJlZCB3aXRoIElBTkEuJnF1 b3Q7Cjwvc3Bhbj4pPGJyPjwvbGk+PC9vbD48L29sPkkgZG9uJiMzOTt0IHRoaW5rIHRoZXkgYXJl IHVzaW5nIG1vZGVsIG51bWJlciBvbmUsIGJ1dCB3ZSBuZWVkIHRvIGZpbmQgb3V0Ljxicj48YnI+ TWFyazxicj48YnI+PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDIvMTUvMDcsIDxi IGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5BbnRob255IEFyaXN0YXI8L2I+ICZsdDs8YSBocmVm PSJtYWlsdG86YXJpc3RhckBsaW5ndWlzdGxpc3Qub3JnIj4KYXJpc3RhckBsaW5ndWlzdGxpc3Qu b3JnPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46 IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPldpdGggYWxsIGR1ZSByZXNw ZWN0LCB0aGlzIHNlZW1zIGxpa2UgYSB2ZXJ5IG9kZCBkaXNjdXNzaW9uIGZyb20gbXkKPGJyPnBl cnNwZWN0aXZlJm5ic3A7Jm5ic3A7YXMgYSBsaW5ndWlzdGljcyBwcm9mZXNzb3IuJm5ic3A7Jm5i c3A7VGhlIGRpc2N1c3Npb24gc2VlbXMgdG88YnI+cHJlc3VwcG9zZSB0aGF0IGFsbCB0aGF0IG1h dHRlcnMgaXMgd2hldGhlciBNaWNyb3NvZnQgaXMgZ29pbmcgdG8gb25lPGJyPmRheSBwcm9kdWNl IGEgdmVyc2lvbiBvZiBXb3JkIGluIE1pZGRsZSBIaWdoIEdlcm1hbiBvciBPbGQgRW5nbGlzaCwg b3I8YnI+aG93IG1hbnkgdGV4dHMgZXhpc3QgaW4gYSBsYW5ndWFnZS4KPGJyPjxicj5CdXQgdGhl IElTTyA2MzkgY29kZXMgYXJlIHVzZWQgZm9yIG11Y2ggbW9yZSB0aGFuIHRoaXMuJm5ic3A7Jm5i c3A7SW4gcGFydGljdWxhciw8YnI+dGhleSBhcmUgdXNlZCB0byBlbnN1cmUgaW50ZXJvcGVyYWJp bGl0eSwgYWxsb3dpbmcgbWF0ZXJpYWwgb2YgdGhlIHNhbWU8YnI+bGluZ3Vpc3RpYyBuYXR1cmUg dG8gYmUgZm91bmQgaW4gc2VhcmNoZXMsIGFuZCB0byBiZSBjb21wYXJlZCB1c2luZyB0aGUKPGJy Pmxpbmd1aXN0aWMgb250b2xvZ2llcyB0aGF0IGFyZSBub3cgYmVpbmcgZGV2ZWxvcGVkLiZuYnNw OyZuYnNwO0lmIEkgYW0gYSBzY2hvbGFyPGJyPnNlYXJjaGluZyBmb3IgdGV4dHMgaW4gT2xkIEVu Z2xpc2ggKG9yIE9sZCBIaWdoIEdlcm1hbiwgZm9yIHRoYXQ8YnI+bWF0dGVyKSBhbmQgZXZlcnlv bmUgaGFzIGJlZW4gY2F2YWxpZXIgZW5vdWdoIHRvIGNvZGUgc3VjaCBtYXRlcmlhbDxicj53aXRo IGVuZyBhbmQgZGV1LCB3aGF0IHRoZSBzZWFyY2ggZW5naW5lcyByZXR1cm4gd2lsbCBiZSB1dHRl cmx5Cjxicj51c2VsZXNzIHRvIG1lLiZuYnNwOyZuYnNwO0kgYW0gZ29pbmcgdG8gYmUgZmxvb2Rl ZCB3aXRoIHN1Y2ggYSBxdWFudGl0eSBvZjxicj5tYXRlcmlhbCBpbiBNb2Rlcm4gRW5nbGlzaCBh bmQgTW9kZXJuIEdlcm1hbiB0aGF0IHNlYXJjaGluZyB0aHJvdWdoIGl0PGJyPndpbGwgYmUgZXNz ZW50aWFsbHkgaW1wb3NzaWJsZS48YnI+PGJyPlNvIGlmIHlvdSByZWFsbHkgYmVsaWV2ZSB0aGF0 IGl0IGRvZXNuJiMzOTt0IG1hdHRlciBpZiB5b3UgY29kZSBFbmdsaXNoCjxicj5tYXRlcmlhbCBh cyBlbmcsIHdoYXRldmVyIGl0cyBwZXJpb2QsIHdoYXQgeW91JiMzOTtyZSByZWFsbHkgc2F5aW5n IGlzIHRoYXQ8YnI+eW91IGRvbiYjMzk7dCByZWFsbHkgY2FyZSBhYm91dCBpbnRlcm9wZXJhYmls aXR5LCBhbmQgdGhhdCB5b3UgZG9uJiMzOTt0IHJlYWxseTxicj5jYXJlIGFib3V0IHNjaG9sYXJz aGlwLjxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7KioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKPGJyPkFudGhvbnkgQXJpc3RhciwgRGly ZWN0b3IsIEluc3RpdHV0ZSBmb3IgTGFuZ3VhZ2UgSW5mb3JtYXRpb24gJmFtcDsgVGVjaG5vbG9n eTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg UHJvZmVzc29yIG9mIExpbmd1aXN0aWNzPGJyPk1vZGVyYXRvciwgTElOR1VJU1QmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUHJpbmNpcGFsIEludmVzdGlnYXRvciwgRU1FTEQgUHJvamVjdDxi cj5MaW5ndWlzdGljcyBQcm9ncmFtCjxicj5EZXB0LiBvZiBFbmdsaXNoJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmFyaXN0 YXJAbGluZ3Vpc3RsaXN0Lm9yZyI+YXJpc3RhckBsaW5ndWlzdGxpc3Qub3JnPC9hPjxicj5FYXN0 ZXJuIE1pY2hpZ2FuIFVuaXZlcnNpdHkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsyMDAwIEh1cm9uIFJpdmVyIERy LCBTdWl0ZSAxMDQ8YnI+WXBzaWxhbnRpLCBNSSA0ODE5Nzxicj5VLlMuQS48YnI+PGJyPgpVUkw6 IDxhIGhyZWY9Imh0dHA6Ly9saW5ndWlzdGxpc3Qub3JnL2FyaXN0YXIvIj5odHRwOi8vbGluZ3Vp c3RsaXN0Lm9yZy9hcmlzdGFyLzwvYT48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+PGJyPiZn dDsgTWFyayBEYXZpcyB3cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7ICZndDsgQXNzdW1lIHRoYXQgb2xk IEN6ZWNoIGlzIGFzIGRpZmZlcmVudCBmcm9tIG1vZGVybiBhcyBmcm8gaXMgZnJvbSBmci4KPGJy PiZndDs8YnI+Jmd0OyBCdXQgaXMgdGhpcyBhIHJlYWwgcHJvYmxlbT8mbmJzcDsmbmJzcDtIb3cg bXVjaCB0b3RhbCBsaXRlcmF0dXJlIGlzIHdyaXR0ZW48YnI+Jmd0OyBhbmQgYXZhaWxhYmxlIGlu IGRpZmZlcmVudCB2YXJpYXRpb25zIG9mIEN6ZWNoPyZuYnNwOyZuYnNwO015IHByZWp1ZGljZSBz YXlzPGJyPiZndDsgdGhhdCBhcyBhIG5hdGlvbiB3aXRoIGEgbGFuZ3VhZ2UgYW5kIGxpdGVyYXR1 cmUgb2YgaXRzIG93biwgQ3plY2gKPGJyPiZndDsgaXMgYWJvdXQgYXMgeW91bmcgYXMgRmlubmlz aCwgTm9yd2VnaWFuIG9yIFNlcmJpYW4sIGkuZS4gMTl0aDxicj4mZ3Q7IGNlbnR1cnkuJm5ic3A7 Jm5ic3A7Q2FuIHlvdSBnaXZlIGFueSBjb25jcmV0ZSBleGFtcGxlcyB3aGVuIG5vdCBoYXZpbmcg YTxicj4mZ3Q7IHNlcGFyYXRlICpjb2RlKiBmb3IgcHJlLXJlbmFpc3NhbmNlIEN6ZWNoIGlzIGEg cHJhY3RpY2FsIHByb2JsZW0/PGJyPiZndDsKPGJyPiZndDsgTGluZ3Vpc3RzIG9mIGNvdXJzZSBo YXZlICpuYW1lcyogZm9yIFN3ZWRpc2ggb2YgYWxsIGFnZXMsIGJ1dCBJPGJyPiZndDsgc2VlIG5v IHJlYWwgdXNlIGZvciBoYXZpbmcgSVNPIG9yIHRoZSBJRVRGIHNwZWNpZnkgbGFuZ3VhZ2U8YnI+ Jmd0OyAqY29kZXMqLiZuYnNwOyZuYnNwO0kgY291bGQgYmUgd3JvbmcsIGJ1dCBpZiBzbyBwbGVh c2UgZW5saWdodGVuIGFuZCBjb3JyZWN0PGJyPiZndDsgbWUuJm5ic3A7Jm5ic3A7Tm9ib2R5IGlz IGdvaW5nIHRvIHRyYW5zbGF0ZSBPcGVuT2ZmaWNlIG9yIE1vemlsbGEgdG8gdGhlCjxicj4mZ3Q7 IGxhbmd1YWdlIHNwb2tlbiBieSB2aWtpbmdzIChPbGQgTm9yc2UpIG9yIHRoZSBTd2VkaXNoIHVz ZWQgZHVyaW5nPGJyPiZndDsgdGhlIEx1dGhlcmFuIHJlZm9ybWF0aW9uIChjYWxsZWQgTmV3IFN3 ZWRpc2gsIGlyb25pY2FsbHkpLjxicj4mZ3Q7PGJyPiZndDsgWWVzLCB0aGVyZSBpcyBub3cgYSBi cmFuY2ggb2YgV2lraXBlZGlhIGluIE9sZCBFbmdsaXNoPGJyPiZndDsgKAo8YSBocmVmPSJodHRw Oi8vYW5nLndpa2lwZWRpYS5vcmciPmFuZy53aWtpcGVkaWEub3JnPC9hPiksIGJ1dCB0aGF0IGlz IGEgcmFyZSBleGNlcHRpb24uJm5ic3A7Jm5ic3A7SSBkb24mIzM5O3QgZXhwZWN0PGJyPiZndDsg dGhpcyB0byBoYXBwZW4gaW4gb3RoZXIgbGFuZ3VhZ2VzLiZuYnNwOyZuYnNwO0FuZyBoYXMgbm93 IDc0NCBhcnRpY2xlcyw8YnI+Jmd0OyBjb21wYXJlZCB0byB0aGUgMTEsMDAwIGFydGljbGVzIG9m IHRoZSBMYXRpbiBXaWtpcGVkaWEuCjxicj48YnI+PGJyPjxicj48YnI+PGJyPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPklldGYtbGFuZ3VhZ2VzIG1h aWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86SWV0Zi1sYW5ndWFnZXNAYWx2ZXN0cmFuZC5u byI+SWV0Zi1sYW5ndWFnZXNAYWx2ZXN0cmFuZC5ubzwvYT48YnI+PGEgaHJlZj0iaHR0cDovL3d3 dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlzdGluZm8vaWV0Zi1sYW5ndWFnZXMiPgpodHRwOi8v d3d3LmFsdmVzdHJhbmQubm8vbWFpbG1hbi9saXN0aW5mby9pZXRmLWxhbmd1YWdlczwvYT48YnI+ PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj5NYXJrCg== ------=_Part_21983_18069180.1171558526177-- --===============1364567260== 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 --===============1364567260==-- From ltru-bounces@ietf.org Thu Feb 15 15:48:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHnWK-0000FY-GJ; Thu, 15 Feb 2007 15:48:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHnWJ-0000FT-RW for ltru@ietf.org; Thu, 15 Feb 2007 15:47:59 -0500 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHnWF-0008Qq-LE for ltru@ietf.org; Thu, 15 Feb 2007 15:47:59 -0500 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 15 Feb 2007 12:47:54 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Thu, 15 Feb 2007 12:47:54 -0800 From: Peter Constable To: LTRU Working Group , "ietf-languages@alvestrand.no" Date: Thu, 15 Feb 2007 12:47:53 -0800 Subject: RE: [Ltru] Re: Ietf-languages Digest, Vol 50, Issue 15 Thread-Topic: [Ltru] Re: Ietf-languages Digest, Vol 50, Issue 15 Thread-Index: AcdRIiaEUnx7ym3gQ3itg/QQHxEWxAABbFxg Message-ID: References: <20070215082323.hiiu4xvtes8wogww@webmail0.linguistlist.org> <30b660a20702150855r11fff871se2cddb412f87169e@mail.gmail.com> In-Reply-To: <30b660a20702150855r11fff871se2cddb412f87169e@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 662324ecda47446db09bfd0a0092c4ba 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="===============1329757311==" Errors-To: ltru-bounces@ietf.org --===============1329757311== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB835795557E1468A4NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB835795557E1468A4NAEXMSGC117re_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Adopting 1 would mean adopting generally across all of ISO 639-3: all entri= es of individual-language scope encompass corresponding historic varieties.= But then, note that historic varieties are relevant only in cases of langu= ages with a long literary tradition that is preserved. For instance, there = may have been an old Naskapi that is distinct from the modern descendent, b= ut there never have been and never will be any records in this putative lan= guage, so there is zero need for an identifier that encompasses it. (Btw, please note: we do *not* code reconstructed protolanguages. ISO 639-3= is explicit about that. So please don=92t anybody suggest we=92d be coding= proto-Naskapi.) So really we=92re just talking about some limited set of cases with a liter= ary tradition. Note that we=92re also only talking about cases in which languages were wel= l-enough developed to maintain a single identify over several hundred years= . That=92s what distinguishes a =93historic=94 language from an =93extinct= =94 language. For instance, there are historic documents in a pre-Columbian= Mixtec variety, but that language identity is not preserved by one specifi= c modern Mixtec variety. And I reject the notion that pre-Columbian Mixtec = together with all the modern Mixtec varieties is a macrolanguage unless som= eone makes the case that there=92s a user scenario in which it is appropria= te to treat all those varieties as one language. So the number of relevant cases is fairly constrained. I don=92t know just = how many there would be, but it=92s going to be a small fraction of all mod= ern languages for which this is relevant. I have a concern with 1 that it would detract from interoperability, for th= e kinds of reasons Anthony mentions. There is a very large amount of usage = in which =93eng=94 is intended to mean specifically modern English, and a v= ery large amount of usage in which =93ces=94 is intended to mean specifical= ly modern Czech. I don=92t see who it would help to decide that these IDs e= ncompass Old English and Old Czech respectively: the average modern-languag= e user isn=92t likely going to be cataloguing content in Old English and Ol= d Czech, and they certainly aren=92t going to be helped by having queries r= eturn records in the historic varieties. As for the specialist, they certai= nly don=92t want to catalog content as all =93eng=94 and =93ces=94, as Anth= ony has made clear. The only scenario in which maybe someone is helped is w= hen the specialist wants a query to return records for all historic varieti= es. I don=92t see why they can=92t use a Boolean operator for that, but eve= n if there was enough need for a single ID, I wouldn=92t be inclined to use= =93eng=92 and =93ces=94 for that purpose: that would be helping the 0.01% = scenario at the detriment of 99.99% of users. Thus, I=92m inclined towards 2. There is certainly willingness in general o= n the part of the ISO 639 JAC to code historic languages, so I have no doub= t that IDs for things like Old Czech etc. would be provided so long as the = need is clear and there=92s a sense that the historic boundaries deemed app= ropriate by philologists, research librarians, etc. are appropriate. Peter ________________________________ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Thursday, February 15, 2007 8:55 AM To: Anthony Aristar Cc: LTRU Working Group; ietf-languages@alvestrand.no Subject: [Ltru] Re: Ietf-languages Digest, Vol 50, Issue 15 Your quotation below omits the true author, and may leave the impression th= at I wrote a number of paragraphs that I do not agree with and did not writ= e. I only wrote "Assume that old Czech ..." -- someone else wrote the "But = is this a real problem...." > Mark Davis wrote: > > > Assume that old Czech is as different from modern as fro is from fr. > > But is this a real problem? How much total literature is written ... That being said, there are two models that ISO could be using. 1. Overlapping. 'eng' means any English, modern or historic. 'ang' means = specifically Old English, a subset of 'eng'. 'ces' means any Czech. There i= s no tag specifically for Old Czech. * so I could tag Beowulf with 'ang' or 'eng', but Shakespeare, Austen= , and Robin Williams only with 'eng'. * Smil Fla=9Aka z Pardubic and V=E1clav Havel are both tagged with 'c= es'. * Requests for BCP 47 variant tags for Shakespearean English (en-SHAK= ESPR) or old Czech (cs-OLDCZECH) would be legitimate. * A request for a variant tag for only modern English (en-MODENGL), t= hus excluding Old English, would be legitimate. 1. Disjoint. 'eng' means only modern English, 'ang' means Old English, 'c= es' means only modern Czech. There is no tag at all (currently) for Old Cze= ch. * so I could tag Beowulf with 'ang' only. * and there is no valid current code for tagging for Smil Fla=9Aka z = Pardubic * A request for BCP 47 variant tags for Shakespearean English (en-SHA= KESPR) would be legitimate * A request for a registered old Czech language tag (oldczech) would = be legitimate. (However "primary languages are strongly RECOMMENDED for reg= istration with ISO 639, and proposals rejected by ISO 639/RA will be closel= y scrutinized before they are registered with IANA." ) I don't think they are using model number one, but we need to find out. Mark On 2/15/07, Anthony Aristar < aristar@linguistlist.org> wrote: With all due respect, this seems like a very odd discussion from my perspective as a linguistics professor. The discussion seems to presuppose that all that matters is whether Microsoft is going to one day produce a version of Word in Middle High German or Old English, or how many texts exist in a language. But the ISO 639 codes are used for much more than this. In particular, they are used to ensure interoperability, allowing material of the same linguistic nature to be found in searches, and to be compared using the linguistic ontologies that are now being developed. If I am a scholar searching for texts in Old English (or Old High German, for that matter) and everyone has been cavalier enough to code such material with eng and deu, what the search engines return will be utterly useless to me. I am going to be flooded with such a quantity of material in Modern English and Modern German that searching through it will be essentially impossible. So if you really believe that it doesn't matter if you code English material as eng, whatever its period, what you're really saying is that you don't really care about interoperability, and that you don't really care about scholarship. ************************************** Anthony Aristar, Director, Institute for Language Information & Technology Professor of Linguistics Moderator, LINGUIST Principal Investigator, EMELD Project Linguistics Program Dept. of English aristar@linguistlist.org Eastern Michigan University 2000 Huron River Dr, Suite 104 Ypsilanti, MI 48197 U.S.A. URL: http://linguistlist.org/aristar/ ************************************** > Mark Davis wrote: > > > Assume that old Czech is as different from modern as fro is from fr. > > But is this a real problem? How much total literature is written > and available in different variations of Czech? My prejudice says > that as a nation with a language and literature of its own, Czech > is about as young as Finnish, Norwegian or Serbian, i.e. 19th > century. Can you give any concrete examples when not having a > separate *code* for pre-renaissance Czech is a practical problem? > > Linguists of course have *names* for Swedish of all ages, but I > see no real use for having ISO or the IETF specify language > *codes*. I could be wrong, but if so please enlighten and correct > me. Nobody is going to translate OpenOffice or Mozilla to the > language spoken by vikings (Old Norse) or the Swedish used during > the Lutheran reformation (called New Swedish, ironically). > > Yes, there is now a branch of Wikipedia in Old English > ( ang.wikipedia.org), but that is a rare except= ion. I don't expect > this to happen in other languages. Ang has now 744 articles, > compared to the 11,000 articles of the Latin Wikipedia. _______________________________________________ Ietf-languages mailing list Ietf-languages@alvestrand.no http://www.alvestrand.no/mailman/listinfo/ietf-languages -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB835795557E1468A4NAEXMSGC117re_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Adopting 1 would mean adopting general= ly across all of ISO 639-3: all entries of individual-language scope encompass corresponding historic varieties. But then, note that historic varieties ar= e relevant only in cases of languages with a long literary tradition that is preserved. For instance, there may have been an old Naskapi that is distinc= t from the modern descendent, but there never have been and never will be any records in this putative language, so there is zero need for an identifier = that encompasses it.

 

(Btw, please note: we do *not* code reconstructed protolanguage= s. ISO 639-3 is explicit about that. So please don=92t anybody suggest we=92d be c= oding proto-Naskapi.)

 

So really we=92re just talking about s= ome limited set of cases with a literary tradition.

 

Note that we=92re also only talking ab= out cases in which languages were well-enough developed to maintain a single identify over several hundred years. That=92s what distinguishes a =93histo= ric=94 language from an =93extinct=94 language. For instance, there are historic d= ocuments in a pre-Columbian Mixtec variety, but that language identity is not preser= ved by one specific modern Mixtec variety. And I reject the notion that pre-Columbian Mixtec together with all the modern Mixtec varieties is a macrolanguage unless someone makes the case that there=92s a user scenario = in which it is appropriate to treat all those varieties as one language.<= /o:p>

 

So the number of relevant cases is fai= rly constrained. I don=92t know just how many there would be, but it=92s going = to be a small fraction of all modern languages for which this is relevant.

 

I have a concern with 1 that it would = detract from interoperability, for the kinds of reasons Anthony mentions. There is = a very large amount of usage in which =93eng=94 is intended to mean specifica= lly modern English, and a very large amount of usage in which =93ces=94 is inte= nded to mean specifically modern Czech. I don=92t see who it would help to decide t= hat these IDs encompass Old English and Old Czech respectively: the average mod= ern-language user isn=92t likely going to be cataloguing content in Old English and Old = Czech, and they certainly aren=92t going to be helped by having queries return rec= ords in the historic varieties. As for the specialist, they certainly don=92t wa= nt to catalog content as all =93eng=94 and =93ces=94, as Anthony has made clear. = The only scenario in which maybe someone is helped is when the specialist wants a qu= ery to return records for all historic varieties. I don=92t see why they can=92= t use a Boolean operator for that, but even if there was enough need for a single ID, I wou= ldn=92t be inclined to use =93eng=92 and =93ces=94 for that purpose: that would be = helping the 0.01% scenario at the detriment of 99.99% of users.

 

Thus, I=92m inclined towards 2. There = is certainly willingness in general on the part of the ISO 639 JAC to code his= toric languages, so I have no doubt that IDs for things like Old Czech etc. would= be provided so long as the need is clear and there=92s a sense that the histor= ic boundaries deemed appropriate by philologists, research librarians, etc. ar= e appropriate.

 

 

 

Peter

 

 

From: Mark Dav= is [mailto:mark.davis@icu-project.org]
Sent: Thursday, February 15,= 2007 8:55 AM
To: Anthony Aristar
Cc: LTRU Working Group; ietf-languages@alvestrand.no
Subject: [Ltru] Re: Ietf-lan= guages Digest, Vol 50, Issue 15

 

Your quotation below omits the true author, and may leave the impression that I wrote a number of paragraphs that I do not agree with and= did not write. I only wrote "Assume that old Czech ..." -- someone el= se wrote the "But is this a real problem...."

> Mark Davis wrote:
>
> > Assume that old Czech is as different from modern as fro is from = fr.
>
> But is this a real problem?  How much total literature is written
...

That being said, there are two models that ISO could be using. <= /span>

  1. Overlapping. 'eng' means any English, modern or historic. 'ang' means specifically Old English, a subset of 'eng'. 'ces' means any Czech. There is no tag specifically for Old Czech.
    1. so I could tag Beowulf with 'ang' or 'eng'= , but Shakespeare, Austen, and Robin Williams only with 'eng'.
    2. Smil Fla=9Aka z Pardubic and V=E1clav Have= l are both tagged with 'ces'.
    3. Requests for BCP 47 variant tags for Shakespearean English (en-SHAKESPR) or old Czech (cs-OLDCZECH) would = be legitimate.
    4. A request for a variant tag for only moder= n English (en-MODENGL), thus excluding Old English, would be legitimate. <= /o:p>
  1. Disjoint. 'eng' means only modern English, 'ang' means Old English, 'ces' means only modern Czech. There is no tag at all (currently) for Old Czech.
    1. so I could tag Beowulf with 'ang' only.
    2. and there is no valid current code for tag= ging for Smil Fla=9Aka z Pardubic
    3. A request for BCP 47 variant tags for Shakespearean English (en-SHAKESPR) would be legitimate
    4. A request for a registered old Czech langu= age tag (oldczech) would be legitimate. (However "primary languages = are strongly RECOMMENDED for registration with ISO 639, and proposals rejected by ISO 639/RA will be closely scrutinized before they are registered with IANA." )

I don't think the= y are using model number one, but we need to find out.

Mark

On 2/15/07, = Anthony Aristar < aristar@linguistlist.org> wrote:

With all due respect, this seems like a very odd discussion from my=
perspective  as a linguistics professor.  The discussio= n seems to
presuppose that all that matters is whether Microsoft is going to one
day produce a version of Word in Middle High German or Old English, or
how many texts exist in a language.

But the ISO 639 codes are used for much more than this.  In particular,
they are used to ensure interoperability, allowing material of the same
linguistic nature to be found in searches, and to be compared using the linguistic ontologies that are now being developed.  If I am a scholar
searching for texts in Old English (or Old High German, for that
matter) and everyone has been cavalier enough to code such material
with eng and deu, what the search engines return will be utterly
useless to me.  I am going to be flooded with such a quantity of<= br> material in Modern English and Modern German that searching through it
will be essentially impossible.

So if you really believe that it doesn't matter if you code English
material as eng, whatever its period, what you're really saying is that
you don't really care about interoperability, and that you don't really
care about scholarship.

            &nb= sp;   **************************************
Anthony Aristar, Director, Institute for Language Information & Technol= ogy
            &nb= sp;      Professor of Linguistics
Moderator, LINGUIST         &n= bsp;     Principal Investigator, EMELD Project
Linguistics Program
Dept. of English           &n= bsp;      aristar@linguistlist.org
Eastern Michigan University           = ; 2000 Huron River Dr, Suite 104
Ypsilanti, MI 48197
U.S.A.

URL: http://linguistlist.org/a= ristar/
            &nb= sp;   **************************************

> Mark Davis wrote:
>
> > Assume that old Czech is as different from modern as fro is from = fr.
>
> But is this a real problem?  How much total literature is written
> and available in different variations of Czech?  My prejudic= e says
> that as a nation with a language and literature of its own, Czech
> is about as young as Finnish, Norwegian or Serbian, i.e. 19th
> century.  Can you give any concrete examples when not having= a
> separate *code* for pre-renaissance Czech is a practical problem?
>
> Linguists of course have *names* for Swedish of all ages, but I
> see no real use for having ISO or the IETF specify language
> *codes*.  I could be wrong, but if so please enlighten and correct
> me.  Nobody is going to translate OpenOffice or Mozilla to t= he
> language spoken by vikings (Old Norse) or the Swedish used during
> the Lutheran reformation (called New Swedish, ironically).
>
> Yes, there is now a branch of Wikipedia in Old English
> ( ang.wikipedia.org), but tha= t is a rare exception.  I don't expect
> this to happen in other languages.  Ang has now 744 articles= ,
> compared to the 11,000 articles of the Latin Wikipedia.





_______________________________________________
Ietf-languages mailing list
Ietf-languages@alvestrand.n= o
http:/= /www.alvestrand.no/mailman/listinfo/ietf-languages




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB835795557E1468A4NAEXMSGC117re_-- --===============1329757311== 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 --===============1329757311==-- From ltru-bounces@ietf.org Thu Feb 15 17:34:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHpBJ-0007qy-9l; Thu, 15 Feb 2007 17:34:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHpBI-0007pA-0V for ltru@ietf.org; Thu, 15 Feb 2007 17:34:24 -0500 Received: from wx-out-0506.google.com ([66.249.82.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHpBE-0006Tl-3V for ltru@ietf.org; Thu, 15 Feb 2007 17:34:23 -0500 Received: by wx-out-0506.google.com with SMTP id h31so756374wxd for ; Thu, 15 Feb 2007 14:34:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=BJor9sfYnjGFQHxdqjfA42WXd0xcthaXXjhLca+7ncJGAUA/3Z/z2DSyuZm+Lbuw8oYy2atDzpcfusO7IXXtem/BetPA01HsZ5wzAUDvX1ZFal37IesU+fDB079zzYtP6yiSU/6caGQsZmHSbVvmoSEJZMKW28Udxo986yw3noc= Received: by 10.90.100.2 with SMTP id x2mr3268385agb.1171578859838; Thu, 15 Feb 2007 14:34:19 -0800 (PST) Received: by 10.90.50.20 with HTTP; Thu, 15 Feb 2007 14:34:19 -0800 (PST) Message-ID: <30b660a20702151434p439c1455pa651bb03acf64269@mail.gmail.com> Date: Thu, 15 Feb 2007 14:34:19 -0800 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: Ietf-languages Digest, Vol 50, Issue 15 In-Reply-To: MIME-Version: 1.0 References: <20070215082323.hiiu4xvtes8wogww@webmail0.linguistlist.org> <30b660a20702150855r11fff871se2cddb412f87169e@mail.gmail.com> X-Google-Sender-Auth: ef078b511c2c529d X-Spam-Score: 0.1 (/) X-Scan-Signature: 2c6813ed945e40b4b5bea39da243c669 Cc: LTRU Working Group , "ietf-languages@alvestrand.no" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0864276221==" Errors-To: ltru-bounces@ietf.org --===============0864276221== Content-Type: multipart/alternative; boundary="----=_Part_10591_4702298.1171578859767" ------=_Part_10591_4702298.1171578859767 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSdtIGluY2xpbmVkIHRvd2FyZHMgIzIgYWxzbywgZm9yIHRoZSByZWFzb25zIHlvdSBjaXRlLiBN eSBwcmltYXJ5IGNvbmNlcm4sCmhvd2V2ZXIsIGlzIHRvIGdldCBhIGRlZmluaXRpdmUgc3RhdGVt ZW50IGZyb20gdGhlIFJBIGFzIHRvIHdoaWNoIG9mIHRoZQpwb2xpY2llcyBpcyB0cnVlLiBUaGF0 LCBmb3IgbWUsIGlzIGZhciBtb3JlIGltcG9ydGFudCB0aGFuIHdoaWNoIHBvbGljeSBpcwphY3R1 YWxseSB1c2VkLgoKTWFyawoKT24gMi8xNS8wNywgUGV0ZXIgQ29uc3RhYmxlIDxwZXRlcmNvbkBt aWNyb3NvZnQuY29tPiB3cm90ZToKPgo+ICBBZG9wdGluZyAxIHdvdWxkIG1lYW4gYWRvcHRpbmcg Z2VuZXJhbGx5IGFjcm9zcyBhbGwgb2YgSVNPIDYzOS0zOiBhbGwKPiBlbnRyaWVzIG9mIGluZGl2 aWR1YWwtbGFuZ3VhZ2Ugc2NvcGUgZW5jb21wYXNzIGNvcnJlc3BvbmRpbmcgaGlzdG9yaWMKPiB2 YXJpZXRpZXMuIEJ1dCB0aGVuLCBub3RlIHRoYXQgaGlzdG9yaWMgdmFyaWV0aWVzIGFyZSByZWxl dmFudCBvbmx5IGluIGNhc2VzCj4gb2YgbGFuZ3VhZ2VzIHdpdGggYSBsb25nIGxpdGVyYXJ5IHRy YWRpdGlvbiB0aGF0IGlzIHByZXNlcnZlZC4gRm9yIGluc3RhbmNlLAo+IHRoZXJlIG1heSBoYXZl IGJlZW4gYW4gb2xkIE5hc2thcGkgdGhhdCBpcyBkaXN0aW5jdCBmcm9tIHRoZSBtb2Rlcm4KPiBk ZXNjZW5kZW50LCBidXQgdGhlcmUgbmV2ZXIgaGF2ZSBiZWVuIGFuZCBuZXZlciB3aWxsIGJlIGFu eSByZWNvcmRzIGluIHRoaXMKPiBwdXRhdGl2ZSBsYW5ndWFnZSwgc28gdGhlcmUgaXMgemVybyBu ZWVkIGZvciBhbiBpZGVudGlmaWVyIHRoYXQgZW5jb21wYXNzZXMKPiBpdC4KPgo+Cj4KPiAoQnR3 LCBwbGVhc2Ugbm90ZTogd2UgZG8gKipub3QqKiBjb2RlIHJlY29uc3RydWN0ZWQgcHJvdG9sYW5n dWFnZXMuIElTTwo+IDYzOS0zIGlzIGV4cGxpY2l0IGFib3V0IHRoYXQuIFNvIHBsZWFzZSBkb24n dCBhbnlib2R5IHN1Z2dlc3Qgd2UnZCBiZSBjb2RpbmcKPiBwcm90by1OYXNrYXBpLikKPgo+Cj4K PiBTbyByZWFsbHkgd2UncmUganVzdCB0YWxraW5nIGFib3V0IHNvbWUgbGltaXRlZCBzZXQgb2Yg Y2FzZXMgd2l0aCBhCj4gbGl0ZXJhcnkgdHJhZGl0aW9uLgo+Cj4KPgo+IE5vdGUgdGhhdCB3ZSdy ZSBhbHNvIG9ubHkgdGFsa2luZyBhYm91dCBjYXNlcyBpbiB3aGljaCBsYW5ndWFnZXMgd2VyZQo+ IHdlbGwtZW5vdWdoIGRldmVsb3BlZCB0byBtYWludGFpbiBhIHNpbmdsZSBpZGVudGlmeSBvdmVy IHNldmVyYWwgaHVuZHJlZAo+IHllYXJzLiBUaGF0J3Mgd2hhdCBkaXN0aW5ndWlzaGVzIGEgImhp c3RvcmljIiBsYW5ndWFnZSBmcm9tIGFuICJleHRpbmN0Igo+IGxhbmd1YWdlLiBGb3IgaW5zdGFu Y2UsIHRoZXJlIGFyZSBoaXN0b3JpYyBkb2N1bWVudHMgaW4gYSBwcmUtQ29sdW1iaWFuCj4gTWl4 dGVjIHZhcmlldHksIGJ1dCB0aGF0IGxhbmd1YWdlIGlkZW50aXR5IGlzIG5vdCBwcmVzZXJ2ZWQg Ynkgb25lIHNwZWNpZmljCj4gbW9kZXJuIE1peHRlYyB2YXJpZXR5LiBBbmQgSSByZWplY3QgdGhl IG5vdGlvbiB0aGF0IHByZS1Db2x1bWJpYW4gTWl4dGVjCj4gdG9nZXRoZXIgd2l0aCBhbGwgdGhl IG1vZGVybiBNaXh0ZWMgdmFyaWV0aWVzIGlzIGEgbWFjcm9sYW5ndWFnZSB1bmxlc3MKPiBzb21l b25lIG1ha2VzIHRoZSBjYXNlIHRoYXQgdGhlcmUncyBhIHVzZXIgc2NlbmFyaW8gaW4gd2hpY2gg aXQgaXMKPiBhcHByb3ByaWF0ZSB0byB0cmVhdCBhbGwgdGhvc2UgdmFyaWV0aWVzIGFzIG9uZSBs YW5ndWFnZS4KPgo+Cj4KPiBTbyB0aGUgbnVtYmVyIG9mIHJlbGV2YW50IGNhc2VzIGlzIGZhaXJs eSBjb25zdHJhaW5lZC4gSSBkb24ndCBrbm93IGp1c3QKPiBob3cgbWFueSB0aGVyZSB3b3VsZCBi ZSwgYnV0IGl0J3MgZ29pbmcgdG8gYmUgYSBzbWFsbCBmcmFjdGlvbiBvZiBhbGwgbW9kZXJuCj4g bGFuZ3VhZ2VzIGZvciB3aGljaCB0aGlzIGlzIHJlbGV2YW50Lgo+Cj4KPgo+IEkgaGF2ZSBhIGNv bmNlcm4gd2l0aCAxIHRoYXQgaXQgd291bGQgZGV0cmFjdCBmcm9tIGludGVyb3BlcmFiaWxpdHks IGZvcgo+IHRoZSBraW5kcyBvZiByZWFzb25zIEFudGhvbnkgbWVudGlvbnMuIFRoZXJlIGlzIGEg dmVyeSBsYXJnZSBhbW91bnQgb2YgdXNhZ2UKPiBpbiB3aGljaCAiZW5nIiBpcyBpbnRlbmRlZCB0 byBtZWFuIHNwZWNpZmljYWxseSBtb2Rlcm4gRW5nbGlzaCwgYW5kIGEgdmVyeQo+IGxhcmdlIGFt b3VudCBvZiB1c2FnZSBpbiB3aGljaCAiY2VzIiBpcyBpbnRlbmRlZCB0byBtZWFuIHNwZWNpZmlj YWxseSBtb2Rlcm4KPiBDemVjaC4gSSBkb24ndCBzZWUgd2hvIGl0IHdvdWxkIGhlbHAgdG8gZGVj aWRlIHRoYXQgdGhlc2UgSURzIGVuY29tcGFzcyBPbGQKPiBFbmdsaXNoIGFuZCBPbGQgQ3plY2gg cmVzcGVjdGl2ZWx5OiB0aGUgYXZlcmFnZSBtb2Rlcm4tbGFuZ3VhZ2UgdXNlciBpc24ndAo+IGxp a2VseSBnb2luZyB0byBiZSBjYXRhbG9ndWluZyBjb250ZW50IGluIE9sZCBFbmdsaXNoIGFuZCBP bGQgQ3plY2gsIGFuZAo+IHRoZXkgY2VydGFpbmx5IGFyZW4ndCBnb2luZyB0byBiZSBoZWxwZWQg YnkgaGF2aW5nIHF1ZXJpZXMgcmV0dXJuIHJlY29yZHMgaW4KPiB0aGUgaGlzdG9yaWMgdmFyaWV0 aWVzLiBBcyBmb3IgdGhlIHNwZWNpYWxpc3QsIHRoZXkgY2VydGFpbmx5IGRvbid0IHdhbnQgdG8K PiBjYXRhbG9nIGNvbnRlbnQgYXMgYWxsICJlbmciIGFuZCAiY2VzIiwgYXMgQW50aG9ueSBoYXMg bWFkZSBjbGVhci4gVGhlIG9ubHkKPiBzY2VuYXJpbyBpbiB3aGljaCBtYXliZSBzb21lb25lIGlz IGhlbHBlZCBpcyB3aGVuIHRoZSBzcGVjaWFsaXN0IHdhbnRzIGEKPiBxdWVyeSB0byByZXR1cm4g cmVjb3JkcyBmb3IgYWxsIGhpc3RvcmljIHZhcmlldGllcy4gSSBkb24ndCBzZWUgd2h5IHRoZXkK PiBjYW4ndCB1c2UgYSBCb29sZWFuIG9wZXJhdG9yIGZvciB0aGF0LCBidXQgZXZlbiBpZiB0aGVy ZSB3YXMgZW5vdWdoIG5lZWQgZm9yCj4gYSBzaW5nbGUgSUQsIEkgd291bGRuJ3QgYmUgaW5jbGlu ZWQgdG8gdXNlICJlbmcnIGFuZCAiY2VzIiBmb3IgdGhhdCBwdXJwb3NlOgo+IHRoYXQgd291bGQg YmUgaGVscGluZyB0aGUgMC4wMSUgc2NlbmFyaW8gYXQgdGhlIGRldHJpbWVudCBvZiA5OS45OSUg b2YKPiB1c2Vycy4KPgo+Cj4KPiBUaHVzLCBJJ20gaW5jbGluZWQgdG93YXJkcyAyLiBUaGVyZSBp cyBjZXJ0YWlubHkgd2lsbGluZ25lc3MgaW4gZ2VuZXJhbCBvbgo+IHRoZSBwYXJ0IG9mIHRoZSBJ U08gNjM5IEpBQyB0byBjb2RlIGhpc3RvcmljIGxhbmd1YWdlcywgc28gSSBoYXZlIG5vIGRvdWJ0 Cj4gdGhhdCBJRHMgZm9yIHRoaW5ncyBsaWtlIE9sZCBDemVjaCBldGMuIHdvdWxkIGJlIHByb3Zp ZGVkIHNvIGxvbmcgYXMgdGhlCj4gbmVlZCBpcyBjbGVhciBhbmQgdGhlcmUncyBhIHNlbnNlIHRo YXQgdGhlIGhpc3RvcmljIGJvdW5kYXJpZXMgZGVlbWVkCj4gYXBwcm9wcmlhdGUgYnkgcGhpbG9s b2dpc3RzLCByZXNlYXJjaCBsaWJyYXJpYW5zLCBldGMuIGFyZSBhcHByb3ByaWF0ZS4KPgo+Cj4K Pgo+Cj4KPgo+IFBldGVyCj4KPgo+Cj4KPiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQo+Cj4gKkZyb206KiBNYXJrIERhdmlzIFttYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5v cmddCj4gKlNlbnQ6KiBUaHVyc2RheSwgRmVicnVhcnkgMTUsIDIwMDcgODo1NSBBTQo+ICpUbzoq IEFudGhvbnkgQXJpc3Rhcgo+ICpDYzoqIExUUlUgV29ya2luZyBHcm91cDsgaWV0Zi1sYW5ndWFn ZXNAYWx2ZXN0cmFuZC5ubwo+ICpTdWJqZWN0OiogW0x0cnVdIFJlOiBJZXRmLWxhbmd1YWdlcyBE aWdlc3QsIFZvbCA1MCwgSXNzdWUgMTUKPgo+Cj4KPiBZb3VyIHF1b3RhdGlvbiBiZWxvdyBvbWl0 cyB0aGUgdHJ1ZSBhdXRob3IsIGFuZCBtYXkgbGVhdmUgdGhlIGltcHJlc3Npb24KPiB0aGF0IEkg d3JvdGUgYSBudW1iZXIgb2YgcGFyYWdyYXBocyB0aGF0IEkgZG8gbm90IGFncmVlIHdpdGggYW5k IGRpZCBub3QKPiB3cml0ZS4gSSBvbmx5IHdyb3RlICJBc3N1bWUgdGhhdCBvbGQgQ3plY2ggLi4u IiAtLSBzb21lb25lIGVsc2Ugd3JvdGUgdGhlCj4gIkJ1dCBpcyB0aGlzIGEgcmVhbCBwcm9ibGVt Li4uLiIKPgo+ID4gTWFyayBEYXZpcyB3cm90ZToKPiA+Cj4gPiA+IEFzc3VtZSB0aGF0IG9sZCBD emVjaCBpcyBhcyBkaWZmZXJlbnQgZnJvbSBtb2Rlcm4gYXMgZnJvIGlzIGZyb20gZnIuCj4gPgo+ ID4gQnV0IGlzIHRoaXMgYSByZWFsIHByb2JsZW0/ICBIb3cgbXVjaCB0b3RhbCBsaXRlcmF0dXJl IGlzIHdyaXR0ZW4KPiAuLi4KPgo+IFRoYXQgYmVpbmcgc2FpZCwgdGhlcmUgYXJlIHR3byBtb2Rl bHMgdGhhdCBJU08gY291bGQgYmUgdXNpbmcuCj4KPiAgICAxLiAqT3ZlcmxhcHBpbmcuIConZW5n JyBtZWFucyBhbnkgRW5nbGlzaCwgbW9kZXJuIG9yIGhpc3RvcmljLiAnYW5nJwo+ICAgIG1lYW5z IHNwZWNpZmljYWxseSBPbGQgRW5nbGlzaCwgYSBzdWJzZXQgb2YgJ2VuZycuICdjZXMnIG1lYW5z IGFueSBDemVjaC4KPiAgICBUaGVyZSBpcyBubyB0YWcgc3BlY2lmaWNhbGx5IGZvciBPbGQgQ3pl Y2guCj4KPgo+ICAgICAxLiBzbyBJIGNvdWxkIHRhZyBCZW93dWxmIHdpdGggJ2FuZycgb3IgJ2Vu ZycsIGJ1dCBTaGFrZXNwZWFyZSwKPiAgICAgICBBdXN0ZW4sIGFuZCBSb2JpbiBXaWxsaWFtcyBv bmx5IHdpdGggJ2VuZycuCj4gICAgICAgMi4gU21pbCBGbGHFoWthIHogUGFyZHViaWMgYW5kIFbD oWNsYXYgSGF2ZWwgYXJlIGJvdGggdGFnZ2VkCj4gICAgICAgd2l0aCAnY2VzJy4KPiAgICAgICAz LiBSZXF1ZXN0cyBmb3IgQkNQIDQ3IHZhcmlhbnQgdGFncyBmb3IgU2hha2VzcGVhcmVhbiBFbmds aXNoCj4gICAgICAgKGVuLVNIQUtFU1BSKSBvciBvbGQgQ3plY2ggKGNzLU9MRENaRUNIKSB3b3Vs ZCBiZSBsZWdpdGltYXRlLgo+ICAgICAgIDQuIEEgcmVxdWVzdCBmb3IgYSB2YXJpYW50IHRhZyBm b3Igb25seSBtb2Rlcm4gRW5nbGlzaAo+ICAgICAgIChlbi1NT0RFTkdMKSwgdGh1cyBleGNsdWRp bmcgT2xkIEVuZ2xpc2gsIHdvdWxkIGJlIGxlZ2l0aW1hdGUuCj4KPgo+ICAgIDEuICpEaXNqb2lu dC4gKidlbmcnIG1lYW5zIG9ubHkgbW9kZXJuIEVuZ2xpc2gsICdhbmcnIG1lYW5zIE9sZAo+ICAg IEVuZ2xpc2gsICdjZXMnIG1lYW5zIG9ubHkgbW9kZXJuIEN6ZWNoLiBUaGVyZSBpcyBubyB0YWcg YXQgYWxsIChjdXJyZW50bHkpCj4gICAgZm9yIE9sZCBDemVjaC4KPgo+Cj4gICAgIDEuIHNvIEkg Y291bGQgdGFnIEJlb3d1bGYgd2l0aCAnYW5nJyBvbmx5Lgo+ICAgICAgIDIuIGFuZCB0aGVyZSBp cyBubyB2YWxpZCBjdXJyZW50IGNvZGUgZm9yIHRhZ2dpbmcgZm9yIFNtaWwKPiAgICAgICBGbGHF oWthIHogUGFyZHViaWMKPiAgICAgICAzLiBBIHJlcXVlc3QgZm9yIEJDUCA0NyB2YXJpYW50IHRh Z3MgZm9yIFNoYWtlc3BlYXJlYW4gRW5nbGlzaAo+ICAgICAgIChlbi1TSEFLRVNQUikgd291bGQg YmUgbGVnaXRpbWF0ZQo+ICAgICAgIDQuIEEgcmVxdWVzdCBmb3IgYSByZWdpc3RlcmVkIG9sZCBD emVjaCBsYW5ndWFnZSB0YWcKPiAgICAgICAob2xkY3plY2gpIHdvdWxkIGJlIGxlZ2l0aW1hdGUu IChIb3dldmVyICJwcmltYXJ5IGxhbmd1YWdlcyBhcmUgc3Ryb25nbHkKPiAgICAgICBSRUNPTU1F TkRFRCBmb3IgcmVnaXN0cmF0aW9uIHdpdGggSVNPIDYzOSwgYW5kIHByb3Bvc2FscyByZWplY3Rl ZCBieSBJU08KPiAgICAgICA2MzkvUkEgd2lsbCBiZSBjbG9zZWx5IHNjcnV0aW5pemVkIGJlZm9y ZSB0aGV5IGFyZSByZWdpc3RlcmVkIHdpdGggSUFOQS4iICkKPgo+IEkgZG9uJ3QgdGhpbmsgdGhl eSBhcmUgdXNpbmcgbW9kZWwgbnVtYmVyIG9uZSwgYnV0IHdlIG5lZWQgdG8gZmluZCBvdXQuCj4K PiBNYXJrCj4KPiBPbiAyLzE1LzA3LCAqQW50aG9ueSBBcmlzdGFyKiA8IGFyaXN0YXJAbGluZ3Vp c3RsaXN0Lm9yZz4gd3JvdGU6Cj4KPiBXaXRoIGFsbCBkdWUgcmVzcGVjdCwgdGhpcyBzZWVtcyBs aWtlIGEgdmVyeSBvZGQgZGlzY3Vzc2lvbiBmcm9tIG15Cj4gcGVyc3BlY3RpdmUgIGFzIGEgbGlu Z3Vpc3RpY3MgcHJvZmVzc29yLiAgVGhlIGRpc2N1c3Npb24gc2VlbXMgdG8KPiBwcmVzdXBwb3Nl IHRoYXQgYWxsIHRoYXQgbWF0dGVycyBpcyB3aGV0aGVyIE1pY3Jvc29mdCBpcyBnb2luZyB0byBv bmUKPiBkYXkgcHJvZHVjZSBhIHZlcnNpb24gb2YgV29yZCBpbiBNaWRkbGUgSGlnaCBHZXJtYW4g b3IgT2xkIEVuZ2xpc2gsIG9yCj4gaG93IG1hbnkgdGV4dHMgZXhpc3QgaW4gYSBsYW5ndWFnZS4K Pgo+IEJ1dCB0aGUgSVNPIDYzOSBjb2RlcyBhcmUgdXNlZCBmb3IgbXVjaCBtb3JlIHRoYW4gdGhp cy4gIEluIHBhcnRpY3VsYXIsCj4gdGhleSBhcmUgdXNlZCB0byBlbnN1cmUgaW50ZXJvcGVyYWJp bGl0eSwgYWxsb3dpbmcgbWF0ZXJpYWwgb2YgdGhlIHNhbWUKPiBsaW5ndWlzdGljIG5hdHVyZSB0 byBiZSBmb3VuZCBpbiBzZWFyY2hlcywgYW5kIHRvIGJlIGNvbXBhcmVkIHVzaW5nIHRoZQo+IGxp bmd1aXN0aWMgb250b2xvZ2llcyB0aGF0IGFyZSBub3cgYmVpbmcgZGV2ZWxvcGVkLiAgSWYgSSBh bSBhIHNjaG9sYXIKPiBzZWFyY2hpbmcgZm9yIHRleHRzIGluIE9sZCBFbmdsaXNoIChvciBPbGQg SGlnaCBHZXJtYW4sIGZvciB0aGF0Cj4gbWF0dGVyKSBhbmQgZXZlcnlvbmUgaGFzIGJlZW4gY2F2 YWxpZXIgZW5vdWdoIHRvIGNvZGUgc3VjaCBtYXRlcmlhbAo+IHdpdGggZW5nIGFuZCBkZXUsIHdo YXQgdGhlIHNlYXJjaCBlbmdpbmVzIHJldHVybiB3aWxsIGJlIHV0dGVybHkKPiB1c2VsZXNzIHRv IG1lLiAgSSBhbSBnb2luZyB0byBiZSBmbG9vZGVkIHdpdGggc3VjaCBhIHF1YW50aXR5IG9mCj4g bWF0ZXJpYWwgaW4gTW9kZXJuIEVuZ2xpc2ggYW5kIE1vZGVybiBHZXJtYW4gdGhhdCBzZWFyY2hp bmcgdGhyb3VnaCBpdAo+IHdpbGwgYmUgZXNzZW50aWFsbHkgaW1wb3NzaWJsZS4KPgo+IFNvIGlm IHlvdSByZWFsbHkgYmVsaWV2ZSB0aGF0IGl0IGRvZXNuJ3QgbWF0dGVyIGlmIHlvdSBjb2RlIEVu Z2xpc2gKPiBtYXRlcmlhbCBhcyBlbmcsIHdoYXRldmVyIGl0cyBwZXJpb2QsIHdoYXQgeW91J3Jl IHJlYWxseSBzYXlpbmcgaXMgdGhhdAo+IHlvdSBkb24ndCByZWFsbHkgY2FyZSBhYm91dCBpbnRl cm9wZXJhYmlsaXR5LCBhbmQgdGhhdCB5b3UgZG9uJ3QgcmVhbGx5Cj4gY2FyZSBhYm91dCBzY2hv bGFyc2hpcC4KPgo+ICAgICAgICAgICAgICAgICAqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKgo+IEFudGhvbnkgQXJpc3RhciwgRGlyZWN0b3IsIEluc3RpdHV0ZSBmb3IgTGFu Z3VhZ2UgSW5mb3JtYXRpb24gJiBUZWNobm9sb2d5Cj4gICAgICAgICAgICAgICAgICAgIFByb2Zl c3NvciBvZiBMaW5ndWlzdGljcwo+IE1vZGVyYXRvciwgTElOR1VJU1QgICAgICAgICAgICAgICBQ cmluY2lwYWwgSW52ZXN0aWdhdG9yLCBFTUVMRCBQcm9qZWN0Cj4gTGluZ3Vpc3RpY3MgUHJvZ3Jh bQo+IERlcHQuIG9mIEVuZ2xpc2ggICAgICAgICAgICAgICAgICBhcmlzdGFyQGxpbmd1aXN0bGlz dC5vcmcKPiBFYXN0ZXJuIE1pY2hpZ2FuIFVuaXZlcnNpdHkgICAgICAgICAgICAyMDAwIEh1cm9u IFJpdmVyIERyLCBTdWl0ZSAxMDQKPiBZcHNpbGFudGksIE1JIDQ4MTk3Cj4gVS5TLkEuCj4KPiBV Ukw6IGh0dHA6Ly9saW5ndWlzdGxpc3Qub3JnL2FyaXN0YXIvCj4gICAgICAgICAgICAgICAgICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCj4KPiA+IE1hcmsgRGF2aXMgd3Jv dGU6Cj4gPgo+ID4gPiBBc3N1bWUgdGhhdCBvbGQgQ3plY2ggaXMgYXMgZGlmZmVyZW50IGZyb20g bW9kZXJuIGFzIGZybyBpcyBmcm9tIGZyLgo+ID4KPiA+IEJ1dCBpcyB0aGlzIGEgcmVhbCBwcm9i bGVtPyAgSG93IG11Y2ggdG90YWwgbGl0ZXJhdHVyZSBpcyB3cml0dGVuCj4gPiBhbmQgYXZhaWxh YmxlIGluIGRpZmZlcmVudCB2YXJpYXRpb25zIG9mIEN6ZWNoPyAgTXkgcHJlanVkaWNlIHNheXMK PiA+IHRoYXQgYXMgYSBuYXRpb24gd2l0aCBhIGxhbmd1YWdlIGFuZCBsaXRlcmF0dXJlIG9mIGl0 cyBvd24sIEN6ZWNoCj4gPiBpcyBhYm91dCBhcyB5b3VuZyBhcyBGaW5uaXNoLCBOb3J3ZWdpYW4g b3IgU2VyYmlhbiwgaS5lLiAxOXRoCj4gPiBjZW50dXJ5LiAgQ2FuIHlvdSBnaXZlIGFueSBjb25j cmV0ZSBleGFtcGxlcyB3aGVuIG5vdCBoYXZpbmcgYQo+ID4gc2VwYXJhdGUgKmNvZGUqIGZvciBw cmUtcmVuYWlzc2FuY2UgQ3plY2ggaXMgYSBwcmFjdGljYWwgcHJvYmxlbT8KPiA+Cj4gPiBMaW5n dWlzdHMgb2YgY291cnNlIGhhdmUgKm5hbWVzKiBmb3IgU3dlZGlzaCBvZiBhbGwgYWdlcywgYnV0 IEkKPiA+IHNlZSBubyByZWFsIHVzZSBmb3IgaGF2aW5nIElTTyBvciB0aGUgSUVURiBzcGVjaWZ5 IGxhbmd1YWdlCj4gPiAqY29kZXMqLiAgSSBjb3VsZCBiZSB3cm9uZywgYnV0IGlmIHNvIHBsZWFz ZSBlbmxpZ2h0ZW4gYW5kIGNvcnJlY3QKPiA+IG1lLiAgTm9ib2R5IGlzIGdvaW5nIHRvIHRyYW5z bGF0ZSBPcGVuT2ZmaWNlIG9yIE1vemlsbGEgdG8gdGhlCj4gPiBsYW5ndWFnZSBzcG9rZW4gYnkg dmlraW5ncyAoT2xkIE5vcnNlKSBvciB0aGUgU3dlZGlzaCB1c2VkIGR1cmluZwo+ID4gdGhlIEx1 dGhlcmFuIHJlZm9ybWF0aW9uIChjYWxsZWQgTmV3IFN3ZWRpc2gsIGlyb25pY2FsbHkpLgo+ID4K PiA+IFllcywgdGhlcmUgaXMgbm93IGEgYnJhbmNoIG9mIFdpa2lwZWRpYSBpbiBPbGQgRW5nbGlz aAo+ID4gKCBhbmcud2lraXBlZGlhLm9yZyksIGJ1dCB0aGF0IGlzIGEgcmFyZSBleGNlcHRpb24u ICBJIGRvbid0IGV4cGVjdAo+ID4gdGhpcyB0byBoYXBwZW4gaW4gb3RoZXIgbGFuZ3VhZ2VzLiAg QW5nIGhhcyBub3cgNzQ0IGFydGljbGVzLAo+ID4gY29tcGFyZWQgdG8gdGhlIDExLDAwMCBhcnRp Y2xlcyBvZiB0aGUgTGF0aW4gV2lraXBlZGlhLgo+Cj4KPgo+Cj4KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IElldGYtbGFuZ3VhZ2VzIG1haWxpbmcg bGlzdAo+IElldGYtbGFuZ3VhZ2VzQGFsdmVzdHJhbmQubm8KPiBodHRwOi8vd3d3LmFsdmVzdHJh bmQubm8vbWFpbG1hbi9saXN0aW5mby9pZXRmLWxhbmd1YWdlcwo+Cj4KPgo+Cj4gLS0KPiBNYXJr Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IEx0 cnUgbWFpbGluZyBsaXN0Cj4gTHRydUBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2x0cnUKPgo+CgoKLS0gCk1hcmsK ------=_Part_10591_4702298.1171578859767 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSYjMzk7bSBpbmNsaW5lZCB0b3dhcmRzICMyIGFsc28sIGZvciB0aGUgcmVhc29ucyB5b3UgY2l0 ZS4gTXkgcHJpbWFyeSBjb25jZXJuLCBob3dldmVyLCBpcyB0byBnZXQgYSBkZWZpbml0aXZlIHN0 YXRlbWVudCBmcm9tIHRoZSBSQSBhcyB0byB3aGljaCBvZiB0aGUgcG9saWNpZXMgaXMgdHJ1ZS4g VGhhdCwgZm9yIG1lLCBpcyBmYXIgbW9yZSBpbXBvcnRhbnQgdGhhbiB3aGljaCBwb2xpY3kgaXMg YWN0dWFsbHkgdXNlZC4KPGJyPjxicj5NYXJrPGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFp bF9xdW90ZSI+T24gMi8xNS8wNywgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPlBldGVyIENv bnN0YWJsZTwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpwZXRlcmNvbkBtaWNyb3NvZnQuY29tIj5w ZXRlcmNvbkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwg MjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsi PgoKCgoKCgoKCgoKCgoKCgo8ZGl2IGxpbms9ImJsdWUiIHZsaW5rPSJibHVlIiBsYW5nPSJFTi1V UyI+Cgo8ZGl2PgoKPHA+PGZvbnQgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBu YXZ5OyI+QWRvcHRpbmcgMSB3b3VsZCBtZWFuIGFkb3B0aW5nIGdlbmVyYWxseQphY3Jvc3MgYWxs IG9mIElTTyA2MzktMzogYWxsIGVudHJpZXMgb2YgaW5kaXZpZHVhbC1sYW5ndWFnZSBzY29wZSBl bmNvbXBhc3MKY29ycmVzcG9uZGluZyBoaXN0b3JpYyB2YXJpZXRpZXMuIEJ1dCB0aGVuLCBub3Rl IHRoYXQgaGlzdG9yaWMgdmFyaWV0aWVzIGFyZQpyZWxldmFudCBvbmx5IGluIGNhc2VzIG9mIGxh bmd1YWdlcyB3aXRoIGEgbG9uZyBsaXRlcmFyeSB0cmFkaXRpb24gdGhhdCBpcwpwcmVzZXJ2ZWQu IEZvciBpbnN0YW5jZSwgdGhlcmUgbWF5IGhhdmUgYmVlbiBhbiBvbGQgTmFza2FwaSB0aGF0IGlz IGRpc3RpbmN0CmZyb20gdGhlIG1vZGVybiBkZXNjZW5kZW50LCBidXQgdGhlcmUgbmV2ZXIgaGF2 ZSBiZWVuIGFuZCBuZXZlciB3aWxsIGJlIGFueQpyZWNvcmRzIGluIHRoaXMgcHV0YXRpdmUgbGFu Z3VhZ2UsIHNvIHRoZXJlIGlzIHplcm8gbmVlZCBmb3IgYW4gaWRlbnRpZmllciB0aGF0CmVuY29t cGFzc2VzIGl0Ljwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgY29sb3I9Im5hdnkiIGZhY2U9 IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8cD48Zm9u dCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij4oQnR3LCBwbGVhc2Ug bm90ZTogd2UgZG8gKjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPm5vdDwvc3Bh bj48L2I+KiBjb2RlIHJlY29uc3RydWN0ZWQgcHJvdG9sYW5ndWFnZXMuIElTTwo2MzktMyBpcyBl eHBsaWNpdCBhYm91dCB0aGF0LiBTbyBwbGVhc2UgZG9uJ3QgYW55Ym9keSBzdWdnZXN0IHdlJ2Qg YmUgY29kaW5nCnByb3RvLU5hc2thcGkuKTwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgY29s b3I9Im5hdnkiIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+Jm5ic3A7PC9zcGFuPjwvZm9u dD48L3A+Cgo8cD48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7 Ij5TbyByZWFsbHkgd2UncmUganVzdCB0YWxraW5nIGFib3V0IHNvbWUKbGltaXRlZCBzZXQgb2Yg Y2FzZXMgd2l0aCBhIGxpdGVyYXJ5IHRyYWRpdGlvbi4gPC9zcGFuPjwvZm9udD48L3A+Cgo8cD48 Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij4mbmJzcDs8L3Nw YW4+PC9mb250PjwvcD4KCjxwPjxmb250IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIgc2l6ZT0i MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xv cjogbmF2eTsiPk5vdGUgdGhhdCB3ZSdyZSBhbHNvIG9ubHkgdGFsa2luZyBhYm91dApjYXNlcyBp biB3aGljaCBsYW5ndWFnZXMgd2VyZSB3ZWxsLWVub3VnaCBkZXZlbG9wZWQgdG8gbWFpbnRhaW4g YSBzaW5nbGUKaWRlbnRpZnkgb3ZlciBzZXZlcmFsIGh1bmRyZWQgeWVhcnMuIFRoYXQncyB3aGF0 IGRpc3Rpbmd1aXNoZXMgYSAiaGlzdG9yaWMiCmxhbmd1YWdlIGZyb20gYW4gImV4dGluY3QiIGxh bmd1YWdlLiBGb3IgaW5zdGFuY2UsIHRoZXJlIGFyZSBoaXN0b3JpYyBkb2N1bWVudHMKaW4gYSBw cmUtQ29sdW1iaWFuIE1peHRlYyB2YXJpZXR5LCBidXQgdGhhdCBsYW5ndWFnZSBpZGVudGl0eSBp cyBub3QgcHJlc2VydmVkCmJ5IG9uZSBzcGVjaWZpYyBtb2Rlcm4gTWl4dGVjIHZhcmlldHkuIEFu ZCBJIHJlamVjdCB0aGUgbm90aW9uIHRoYXQKcHJlLUNvbHVtYmlhbiBNaXh0ZWMgdG9nZXRoZXIg d2l0aCBhbGwgdGhlIG1vZGVybiBNaXh0ZWMgdmFyaWV0aWVzIGlzIGEKbWFjcm9sYW5ndWFnZSB1 bmxlc3Mgc29tZW9uZSBtYWtlcyB0aGUgY2FzZSB0aGF0IHRoZXJlJ3MgYSB1c2VyIHNjZW5hcmlv IGluCndoaWNoIGl0IGlzIGFwcHJvcHJpYXRlIHRvIHRyZWF0IGFsbCB0aG9zZSB2YXJpZXRpZXMg YXMgb25lIGxhbmd1YWdlLjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgY29sb3I9Im5hdnki IGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250 LWZhbWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8 cD48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij5TbyB0aGUg bnVtYmVyIG9mIHJlbGV2YW50IGNhc2VzIGlzIGZhaXJseQpjb25zdHJhaW5lZC4gSSBkb24ndCBr bm93IGp1c3QgaG93IG1hbnkgdGhlcmUgd291bGQgYmUsIGJ1dCBpdCdzIGdvaW5nIHRvIGJlIGEK c21hbGwgZnJhY3Rpb24gb2YgYWxsIG1vZGVybiBsYW5ndWFnZXMgZm9yIHdoaWNoIHRoaXMgaXMg cmVsZXZhbnQuPC9zcGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0i QXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250 IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPkkgaGF2ZSBhIGNvbmNl cm4gd2l0aCAxIHRoYXQgaXQgd291bGQgZGV0cmFjdApmcm9tIGludGVyb3BlcmFiaWxpdHksIGZv ciB0aGUga2luZHMgb2YgcmVhc29ucyBBbnRob255IG1lbnRpb25zLiBUaGVyZSBpcyBhCnZlcnkg bGFyZ2UgYW1vdW50IG9mIHVzYWdlIGluIHdoaWNoICJlbmciIGlzIGludGVuZGVkIHRvIG1lYW4g c3BlY2lmaWNhbGx5Cm1vZGVybiBFbmdsaXNoLCBhbmQgYSB2ZXJ5IGxhcmdlIGFtb3VudCBvZiB1 c2FnZSBpbiB3aGljaCAiY2VzIiBpcyBpbnRlbmRlZCB0bwptZWFuIHNwZWNpZmljYWxseSBtb2Rl cm4gQ3plY2guIEkgZG9uJ3Qgc2VlIHdobyBpdCB3b3VsZCBoZWxwIHRvIGRlY2lkZSB0aGF0CnRo ZXNlIElEcyBlbmNvbXBhc3MgT2xkIEVuZ2xpc2ggYW5kIE9sZCBDemVjaCByZXNwZWN0aXZlbHk6 IHRoZSBhdmVyYWdlIG1vZGVybi1sYW5ndWFnZQp1c2VyIGlzbid0IGxpa2VseSBnb2luZyB0byBi ZSBjYXRhbG9ndWluZyBjb250ZW50IGluIE9sZCBFbmdsaXNoIGFuZCBPbGQgQ3plY2gsCmFuZCB0 aGV5IGNlcnRhaW5seSBhcmVuJ3QgZ29pbmcgdG8gYmUgaGVscGVkIGJ5IGhhdmluZyBxdWVyaWVz IHJldHVybiByZWNvcmRzCmluIHRoZSBoaXN0b3JpYyB2YXJpZXRpZXMuIEFzIGZvciB0aGUgc3Bl Y2lhbGlzdCwgdGhleSBjZXJ0YWlubHkgZG9uJ3Qgd2FudCB0bwpjYXRhbG9nIGNvbnRlbnQgYXMg YWxsICJlbmciIGFuZCAiY2VzIiwgYXMgQW50aG9ueSBoYXMgbWFkZSBjbGVhci4gVGhlIG9ubHkK c2NlbmFyaW8gaW4gd2hpY2ggbWF5YmUgc29tZW9uZSBpcyBoZWxwZWQgaXMgd2hlbiB0aGUgc3Bl Y2lhbGlzdCB3YW50cyBhIHF1ZXJ5CnRvIHJldHVybiByZWNvcmRzIGZvciBhbGwgaGlzdG9yaWMg dmFyaWV0aWVzLiBJIGRvbid0IHNlZSB3aHkgdGhleSBjYW4ndCB1c2UgYSBCb29sZWFuCm9wZXJh dG9yIGZvciB0aGF0LCBidXQgZXZlbiBpZiB0aGVyZSB3YXMgZW5vdWdoIG5lZWQgZm9yIGEgc2lu Z2xlIElELCBJIHdvdWxkbid0CmJlIGluY2xpbmVkIHRvIHVzZSAiZW5nJyBhbmQgImNlcyIgZm9y IHRoYXQgcHVycG9zZTogdGhhdCB3b3VsZCBiZSBoZWxwaW5nIHRoZSAwLjAxJQpzY2VuYXJpbyBh dCB0aGUgZGV0cmltZW50IG9mIDk5Ljk5JSBvZiB1c2Vycy48L3NwYW4+PC9mb250PjwvcD4KCjxw Pjxmb250IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPiZuYnNwOzwv c3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIiBzaXpl PSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWw7IGNv bG9yOiBuYXZ5OyI+VGh1cywgSSdtIGluY2xpbmVkIHRvd2FyZHMgMi4gVGhlcmUgaXMKY2VydGFp bmx5IHdpbGxpbmduZXNzIGluIGdlbmVyYWwgb24gdGhlIHBhcnQgb2YgdGhlIElTTyA2MzkgSkFD IHRvIGNvZGUgaGlzdG9yaWMKbGFuZ3VhZ2VzLCBzbyBJIGhhdmUgbm8gZG91YnQgdGhhdCBJRHMg Zm9yIHRoaW5ncyBsaWtlIE9sZCBDemVjaCBldGMuIHdvdWxkIGJlCnByb3ZpZGVkIHNvIGxvbmcg YXMgdGhlIG5lZWQgaXMgY2xlYXIgYW5kIHRoZXJlJ3MgYSBzZW5zZSB0aGF0IHRoZSBoaXN0b3Jp Ywpib3VuZGFyaWVzIGRlZW1lZCBhcHByb3ByaWF0ZSBieSBwaGlsb2xvZ2lzdHMsIHJlc2VhcmNo IGxpYnJhcmlhbnMsIGV0Yy4gYXJlCmFwcHJvcHJpYXRlLjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+ PGZvbnQgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+Jm5ic3A7PC9z cGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9 IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29s b3I6IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IGNvbG9yPSJuYXZ5 IiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgoK PHA+PGZvbnQgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+UGV0ZXI8 L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIgc2l6 ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBj b2xvcjogbmF2eTsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgY29sb3I9Im5h dnkiIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+ Cgo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXIt Y29sb3I6IC1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10 ZXh0LWNvbG9yIGJsdWU7IGJvcmRlci13aWR0aDogbWVkaXVtIG1lZGl1bSBtZWRpdW0gMS41cHQ7 IHBhZGRpbmc6IDBpbiAwaW4gMGluIDRwdDsiPgoKPGRpdj4KCjxkaXYgc3R5bGU9InRleHQtYWxp Z246IGNlbnRlcjsiIGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg c2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPgoKPGhyIGFsaWduPSJjZW50 ZXIiIHNpemU9IjIiIHdpZHRoPSIxMDAlIj4KCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+Cgo8cD48Yj48 Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBUYWhvbWE7IGZvbnQtd2VpZ2h0OiBib2xkOyI+RnJvbTo8L3NwYW4+PC9m b250PjwvYj48Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWE7Ij4gTWFyayBEYXZpcwpbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG9u Y2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5tYXJr LmRhdmlzQGljdS1wcm9qZWN0Lm9yZzwvYT5dIDxicj4KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OiBib2xkOyI+U2VudDo8L3NwYW4+PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMTUsIDIwMDcK ODo1NSBBTTxicj4KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+VG86PC9zcGFu PjwvYj4gQW50aG9ueSBBcmlzdGFyPGJyPgo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJv bGQ7Ij5DYzo8L3NwYW4+PC9iPiBMVFJVIFdvcmtpbmcgR3JvdXA7CjxhIGhyZWY9Im1haWx0bzpp ZXRmLWxhbmd1YWdlc0BhbHZlc3RyYW5kLm5vIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0 dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmlldGYtbGFuZ3VhZ2Vz QGFsdmVzdHJhbmQubm88L2E+PGJyPgo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7 Ij5TdWJqZWN0Ojwvc3Bhbj48L2I+IFtMdHJ1XSBSZTogSWV0Zi1sYW5ndWFnZXMKRGlnZXN0LCBW b2wgNTAsIElzc3VlIDE1PC9zcGFuPjwvZm9udD48L3A+Cgo8L2Rpdj48ZGl2PjxzcGFuIGNsYXNz PSJlIiBpZD0icV8xMTBjNzI5OTNhYzNjYjE1XzEiPgoKPHA+PGZvbnQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+Jm5ic3A7PC9z cGFuPjwvZm9udD48L3A+Cgo8cD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij5Zb3VyIHF1b3RhdGlvbiBiZWxvdyBvbWl0 cyB0aGUgdHJ1ZSBhdXRob3IsIGFuZCBtYXkgbGVhdmUgdGhlCmltcHJlc3Npb24gdGhhdCBJIHdy b3RlIGEgbnVtYmVyIG9mIHBhcmFncmFwaHMgdGhhdCBJIGRvIG5vdCBhZ3JlZSB3aXRoIGFuZCBk aWQKbm90IHdyaXRlLiBJIG9ubHkgd3JvdGUgJnF1b3Q7QXNzdW1lIHRoYXQgb2xkIEN6ZWNoIC4u LiZxdW90OyAtLSBzb21lb25lIGVsc2UKd3JvdGUgdGhlICZxdW90O0J1dCBpcyB0aGlzIGEgcmVh bCBwcm9ibGVtLi4uLiZxdW90OyA8YnI+Cjxicj4KJmd0OyBNYXJrIERhdmlzIHdyb3RlOjxicj4K Jmd0Ozxicj4KJmd0OyAmZ3Q7IEFzc3VtZSB0aGF0IG9sZCBDemVjaCBpcyBhcyBkaWZmZXJlbnQg ZnJvbSBtb2Rlcm4gYXMgZnJvIGlzIGZyb20gZnIuPGJyPgomZ3Q7PGJyPgomZ3Q7IEJ1dCBpcyB0 aGlzIGEgcmVhbCBwcm9ibGVtPyZuYnNwOyZuYnNwO0hvdyBtdWNoIHRvdGFsIGxpdGVyYXR1cmUg aXMKd3JpdHRlbjxicj4KLi4uPGJyPgo8YnI+ClRoYXQgYmVpbmcgc2FpZCwgdGhlcmUgYXJlIHR3 byBtb2RlbHMgdGhhdCBJU08gY291bGQgYmUgdXNpbmcuIDwvc3Bhbj48L2ZvbnQ+PC9wPgoKPG9s IHN0YXJ0PSIxIiB0eXBlPSIxIj4KIDxsaT48Yj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtd2VpZ2h0OiBib2xk OyI+T3ZlcmxhcHBpbmcuIDwvc3Bhbj48L2ZvbnQ+PC9iPiYjMzk7ZW5nJiMzOTsKICAgICBtZWFu cyBhbnkgRW5nbGlzaCwgbW9kZXJuIG9yIGhpc3RvcmljLiAmIzM5O2FuZyYjMzk7IG1lYW5zIHNw ZWNpZmljYWxseSBPbGQKICAgICBFbmdsaXNoLCBhIHN1YnNldCBvZiAmIzM5O2VuZyYjMzk7LiAm IzM5O2NlcyYjMzk7IG1lYW5zIGFueSBDemVjaC4gVGhlcmUgaXMgbm8gdGFnCiAgICAgc3BlY2lm aWNhbGx5IGZvciBPbGQgQ3plY2guIDwvbGk+Cjwvb2w+Cgo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEi PgogPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4KICA8bGk+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+c28gSSBjb3VsZCB0 YWcgQmVvd3VsZiB3aXRoICYjMzk7YW5nJiMzOTsgb3IgJiMzOTtlbmcmIzM5OywgYnV0CiAgICAg IFNoYWtlc3BlYXJlLCBBdXN0ZW4sIGFuZCBSb2JpbiBXaWxsaWFtcyBvbmx5IHdpdGggJiMzOTtl bmcmIzM5Oy48L3NwYW4+PC9mb250PjwvbGk+CiAgPGxpPjxmb250IGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPlNtaWwgRmxhxaFr YSB6IFBhcmR1YmljIGFuZCBWw6FjbGF2IEhhdmVsIGFyZSBib3RoCiAgICAgIHRhZ2dlZCB3aXRo ICYjMzk7Y2VzJiMzOTsuIDwvc3Bhbj48L2ZvbnQ+PC9saT4KICA8bGk+PGZvbnQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+UmVx dWVzdHMgZm9yIEJDUCA0NyB2YXJpYW50IHRhZ3MgZm9yCiAgICAgIFNoYWtlc3BlYXJlYW4gRW5n bGlzaCAoZW4tU0hBS0VTUFIpIG9yIG9sZCBDemVjaCAoY3MtT0xEQ1pFQ0gpIHdvdWxkIGJlCiAg ICAgIGxlZ2l0aW1hdGUuPC9zcGFuPjwvZm9udD48L2xpPgogIDxsaT48Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij5BIHJl cXVlc3QgZm9yIGEgdmFyaWFudCB0YWcgZm9yIG9ubHkgbW9kZXJuIEVuZ2xpc2gKICAgICAgKGVu LU1PREVOR0wpLCB0aHVzIGV4Y2x1ZGluZyBPbGQgRW5nbGlzaCwgd291bGQgYmUgbGVnaXRpbWF0 ZS4gPC9zcGFuPjwvZm9udD48L2xpPgogPC9vbD4KPC9vbD4KCjxvbCBzdGFydD0iMiIgdHlwZT0i MSI+CiA8bGk+PGI+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LXdlaWdodDogYm9sZDsiPkRpc2pvaW50LiA8L3Nw YW4+PC9mb250PjwvYj4mIzM5O2VuZyYjMzk7CiAgICAgbWVhbnMgb25seSBtb2Rlcm4gRW5nbGlz aCwgJiMzOTthbmcmIzM5OyBtZWFucyBPbGQgRW5nbGlzaCwgJiMzOTtjZXMmIzM5OyBtZWFucyBv bmx5CiAgICAgbW9kZXJuIEN6ZWNoLgogICAgIFRoZXJlIGlzIG5vIHRhZyBhdCBhbGwgKGN1cnJl bnRseSkgZm9yIE9sZCBDemVjaC4gPC9saT4KPC9vbD4KCjxvbCBzdGFydD0iMiIgdHlwZT0iMSI+ CiA8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPgogIDxsaT48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij5zbyBJIGNvdWxkIHRh ZyBCZW93dWxmIHdpdGggJiMzOTthbmcmIzM5OyBvbmx5Ljwvc3Bhbj48L2ZvbnQ+PC9saT4KICA8 bGk+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMnB0OyI+YW5kIHRoZXJlIGlzIG5vIHZhbGlkIGN1cnJlbnQgY29kZSBmb3IgdGFn Z2luZwogICAgICBmb3IgU21pbCBGbGHFoWthIHogUGFyZHViaWM8L3NwYW4+PC9mb250PjwvbGk+ CiAgPGxpPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTJwdDsiPkEgcmVxdWVzdCBmb3IgQkNQIDQ3IHZhcmlhbnQgdGFncyBmb3IK ICAgICAgU2hha2VzcGVhcmVhbiBFbmdsaXNoIChlbi1TSEFLRVNQUikgd291bGQgYmUgbGVnaXRp bWF0ZSA8L3NwYW4+PC9mb250PjwvbGk+CiAgPGxpPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21h biIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPkEgcmVxdWVzdCBmb3Ig YSByZWdpc3RlcmVkIG9sZCBDemVjaCBsYW5ndWFnZQogICAgICB0YWcgKG9sZGN6ZWNoKSB3b3Vs ZCBiZSBsZWdpdGltYXRlLiAoSG93ZXZlciAmcXVvdDtwcmltYXJ5IGxhbmd1YWdlcyBhcmUKICAg ICAgc3Ryb25nbHkgUkVDT01NRU5ERUQgZm9yIHJlZ2lzdHJhdGlvbiB3aXRoIElTTyA2MzksIGFu ZCBwcm9wb3NhbHMKICAgICAgcmVqZWN0ZWQgYnkgSVNPIDYzOS9SQSB3aWxsIGJlIGNsb3NlbHkg c2NydXRpbml6ZWQgYmVmb3JlIHRoZXkgYXJlCiAgICAgIHJlZ2lzdGVyZWQgd2l0aCBJQU5BLiZx dW90OyApPC9zcGFuPjwvZm9udD48L2xpPgogPC9vbD4KPC9vbD4KCjxwIHN0eWxlPSJtYXJnaW4t Ym90dG9tOiAxMnB0OyI+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+SSBkb24mIzM5O3QgdGhpbmsgdGhleSBhcmUKdXNp bmcgbW9kZWwgbnVtYmVyIG9uZSwgYnV0IHdlIG5lZWQgdG8gZmluZCBvdXQuPGJyPgo8YnI+Ck1h cms8L3NwYW4+PC9mb250PjwvcD4KCjxkaXY+Cgo8cD48c3Bhbj48Zm9udCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij5PbiAyLzE1 LzA3LCA8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5BbnRob255CkFyaXN0YXI8 L3NwYW4+PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyaXN0YXJAbGluZ3Vpc3RsaXN0Lm9yZyIg dGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93 LGV2ZW50LHRoaXMpIj4KYXJpc3RhckBsaW5ndWlzdGxpc3Qub3JnPC9hPiZndDsgd3JvdGU6PC9z cGFuPjwvZm9udD48L3NwYW4+PC9wPgoKPHA+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBz aXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+V2l0aCBhbGwgZHVlIHJlc3Bl Y3QsIHRoaXMgc2VlbXMgbGlrZSBhIHZlcnkgb2RkIGRpc2N1c3Npb24gZnJvbSBteSA8YnI+CnBl cnNwZWN0aXZlJm5ic3A7Jm5ic3A7YXMgYSBsaW5ndWlzdGljcyBwcm9mZXNzb3IuJm5ic3A7Jm5i c3A7VGhlIGRpc2N1c3Npb24Kc2VlbXMgdG88YnI+CnByZXN1cHBvc2UgdGhhdCBhbGwgdGhhdCBt YXR0ZXJzIGlzIHdoZXRoZXIgTWljcm9zb2Z0IGlzIGdvaW5nIHRvIG9uZTxicj4KZGF5IHByb2R1 Y2UgYSB2ZXJzaW9uIG9mIFdvcmQgaW4gTWlkZGxlIEhpZ2ggR2VybWFuIG9yIE9sZCBFbmdsaXNo LCBvcjxicj4KaG93IG1hbnkgdGV4dHMgZXhpc3QgaW4gYSBsYW5ndWFnZS4gPGJyPgo8YnI+CkJ1 dCB0aGUgSVNPIDYzOSBjb2RlcyBhcmUgdXNlZCBmb3IgbXVjaCBtb3JlIHRoYW4gdGhpcy4mbmJz cDsmbmJzcDtJbgpwYXJ0aWN1bGFyLDxicj4KdGhleSBhcmUgdXNlZCB0byBlbnN1cmUgaW50ZXJv cGVyYWJpbGl0eSwgYWxsb3dpbmcgbWF0ZXJpYWwgb2YgdGhlIHNhbWU8YnI+Cmxpbmd1aXN0aWMg bmF0dXJlIHRvIGJlIGZvdW5kIGluIHNlYXJjaGVzLCBhbmQgdG8gYmUgY29tcGFyZWQgdXNpbmcg dGhlIDxicj4KbGluZ3Vpc3RpYyBvbnRvbG9naWVzIHRoYXQgYXJlIG5vdyBiZWluZyBkZXZlbG9w ZWQuJm5ic3A7Jm5ic3A7SWYgSSBhbSBhCnNjaG9sYXI8YnI+CnNlYXJjaGluZyBmb3IgdGV4dHMg aW4gT2xkIEVuZ2xpc2ggKG9yIE9sZCBIaWdoIEdlcm1hbiwgZm9yIHRoYXQ8YnI+Cm1hdHRlcikg YW5kIGV2ZXJ5b25lIGhhcyBiZWVuIGNhdmFsaWVyIGVub3VnaCB0byBjb2RlIHN1Y2ggbWF0ZXJp YWw8YnI+CndpdGggZW5nIGFuZCBkZXUsIHdoYXQgdGhlIHNlYXJjaCBlbmdpbmVzIHJldHVybiB3 aWxsIGJlIHV0dGVybHkgPGJyPgp1c2VsZXNzIHRvIG1lLiZuYnNwOyZuYnNwO0kgYW0gZ29pbmcg dG8gYmUgZmxvb2RlZCB3aXRoIHN1Y2ggYSBxdWFudGl0eSBvZjxicj4KbWF0ZXJpYWwgaW4gTW9k ZXJuIEVuZ2xpc2ggYW5kIE1vZGVybiBHZXJtYW4gdGhhdCBzZWFyY2hpbmcgdGhyb3VnaCBpdDxi cj4Kd2lsbCBiZSBlc3NlbnRpYWxseSBpbXBvc3NpYmxlLjxicj4KPGJyPgpTbyBpZiB5b3UgcmVh bGx5IGJlbGlldmUgdGhhdCBpdCBkb2VzbiYjMzk7dCBtYXR0ZXIgaWYgeW91IGNvZGUgRW5nbGlz aCA8YnI+Cm1hdGVyaWFsIGFzIGVuZywgd2hhdGV2ZXIgaXRzIHBlcmlvZCwgd2hhdCB5b3UmIzM5 O3JlIHJlYWxseSBzYXlpbmcgaXMgdGhhdDxicj4KeW91IGRvbiYjMzk7dCByZWFsbHkgY2FyZSBh Ym91dCBpbnRlcm9wZXJhYmlsaXR5LCBhbmQgdGhhdCB5b3UgZG9uJiMzOTt0IHJlYWxseTxicj4K Y2FyZSBhYm91dCBzY2hvbGFyc2hpcC48YnI+Cjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKPGJy PgpBbnRob255IEFyaXN0YXIsIERpcmVjdG9yLCBJbnN0aXR1dGUgZm9yIExhbmd1YWdlIEluZm9y bWF0aW9uICZhbXA7IFRlY2hub2xvZ3k8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOwpQcm9mZXNzb3Igb2YgTGluZ3Vpc3RpY3M8YnI+Ck1vZGVy YXRvciwgTElOR1VJU1QmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKUHJpbmNpcGFsIEludmVz dGlnYXRvciwgRU1FTEQgUHJvamVjdDxicj4KTGluZ3Vpc3RpY3MgUHJvZ3JhbSA8YnI+CkRlcHQu IG9mCkVuZ2xpc2gmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8YSBocmVmPSJtYWlsdG86YXJpc3RhckBsaW5ndWlzdGxpc3Qub3JnIiB0YXJnZXQ9Il9i bGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhp cykiPmFyaXN0YXJAbGluZ3Vpc3RsaXN0Lm9yZzwvYT48YnI+CkVhc3Rlcm4gTWljaGlnYW4KVW5p dmVyc2l0eSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzIwMDAKSHVyb24gUml2ZXIgRHIsIFN1aXRlIDEwNDxicj4K WXBzaWxhbnRpLCBNSSA0ODE5Nzxicj4KVS5TLkEuPGJyPgo8YnI+ClVSTDogPGEgaHJlZj0iaHR0 cDovL2xpbmd1aXN0bGlzdC5vcmcvYXJpc3Rhci8iIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJy ZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aHR0cDovL2xpbmd1 aXN0bGlzdC5vcmcvYXJpc3Rhci88L2E+PGJyPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4KPGJy PgomZ3Q7IE1hcmsgRGF2aXMgd3JvdGU6PGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsgQXNzdW1lIHRo YXQgb2xkIEN6ZWNoIGlzIGFzIGRpZmZlcmVudCBmcm9tIG1vZGVybiBhcyBmcm8gaXMgZnJvbSBm ci4gPGJyPgomZ3Q7PGJyPgomZ3Q7IEJ1dCBpcyB0aGlzIGEgcmVhbCBwcm9ibGVtPyZuYnNwOyZu YnNwO0hvdyBtdWNoIHRvdGFsIGxpdGVyYXR1cmUgaXMKd3JpdHRlbjxicj4KJmd0OyBhbmQgYXZh aWxhYmxlIGluIGRpZmZlcmVudCB2YXJpYXRpb25zIG9mIEN6ZWNoPyZuYnNwOyZuYnNwO015IHBy ZWp1ZGljZQpzYXlzPGJyPgomZ3Q7IHRoYXQgYXMgYSBuYXRpb24gd2l0aCBhIGxhbmd1YWdlIGFu ZCBsaXRlcmF0dXJlIG9mIGl0cyBvd24sIEN6ZWNoIDxicj4KJmd0OyBpcyBhYm91dCBhcyB5b3Vu ZyBhcyBGaW5uaXNoLCBOb3J3ZWdpYW4gb3IgU2VyYmlhbiwgaS5lLiAxOXRoPGJyPgomZ3Q7IGNl bnR1cnkuJm5ic3A7Jm5ic3A7Q2FuIHlvdSBnaXZlIGFueSBjb25jcmV0ZSBleGFtcGxlcyB3aGVu IG5vdCBoYXZpbmcgYTxicj4KJmd0OyBzZXBhcmF0ZSAqY29kZSogZm9yIHByZS1yZW5haXNzYW5j ZSBDemVjaCBpcyBhIHByYWN0aWNhbCBwcm9ibGVtPzxicj4KJmd0OyA8YnI+CiZndDsgTGluZ3Vp c3RzIG9mIGNvdXJzZSBoYXZlICpuYW1lcyogZm9yIFN3ZWRpc2ggb2YgYWxsIGFnZXMsIGJ1dCBJ PGJyPgomZ3Q7IHNlZSBubyByZWFsIHVzZSBmb3IgaGF2aW5nIElTTyBvciB0aGUgSUVURiBzcGVj aWZ5IGxhbmd1YWdlPGJyPgomZ3Q7ICpjb2RlcyouJm5ic3A7Jm5ic3A7SSBjb3VsZCBiZSB3cm9u ZywgYnV0IGlmIHNvIHBsZWFzZSBlbmxpZ2h0ZW4gYW5kCmNvcnJlY3Q8YnI+CiZndDsgbWUuJm5i c3A7Jm5ic3A7Tm9ib2R5IGlzIGdvaW5nIHRvIHRyYW5zbGF0ZSBPcGVuT2ZmaWNlIG9yIE1vemls bGEgdG8gdGhlIDxicj4KJmd0OyBsYW5ndWFnZSBzcG9rZW4gYnkgdmlraW5ncyAoT2xkIE5vcnNl KSBvciB0aGUgU3dlZGlzaCB1c2VkIGR1cmluZzxicj4KJmd0OyB0aGUgTHV0aGVyYW4gcmVmb3Jt YXRpb24gKGNhbGxlZCBOZXcgU3dlZGlzaCwgaXJvbmljYWxseSkuPGJyPgomZ3Q7PGJyPgomZ3Q7 IFllcywgdGhlcmUgaXMgbm93IGEgYnJhbmNoIG9mIFdpa2lwZWRpYSBpbiBPbGQgRW5nbGlzaDxi cj4KJmd0OyAoIDxhIGhyZWY9Imh0dHA6Ly9hbmcud2lraXBlZGlhLm9yZyIgdGFyZ2V0PSJfYmxh bmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp Ij5hbmcud2lraXBlZGlhLm9yZzwvYT4pLCBidXQgdGhhdCBpcyBhCnJhcmUgZXhjZXB0aW9uLiZu YnNwOyZuYnNwO0kgZG9uJiMzOTt0IGV4cGVjdDxicj4KJmd0OyB0aGlzIHRvIGhhcHBlbiBpbiBv dGhlciBsYW5ndWFnZXMuJm5ic3A7Jm5ic3A7QW5nIGhhcyBub3cgNzQ0IGFydGljbGVzLDxicj4K Jmd0OyBjb21wYXJlZCB0byB0aGUgMTEsMDAwIGFydGljbGVzIG9mIHRoZSBMYXRpbiBXaWtpcGVk aWEuIDxicj4KPGJyPgo8YnI+Cjxicj4KPGJyPgo8YnI+Cl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPgpJZXRmLWxhbmd1YWdlcyBtYWlsaW5nIGxpc3Q8 YnI+CjxhIGhyZWY9Im1haWx0bzpJZXRmLWxhbmd1YWdlc0BhbHZlc3RyYW5kLm5vIiB0YXJnZXQ9 Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQs dGhpcykiPklldGYtbGFuZ3VhZ2VzQGFsdmVzdHJhbmQubm88L2E+PGJyPgo8YSBocmVmPSJodHRw Oi8vd3d3LmFsdmVzdHJhbmQubm8vbWFpbG1hbi9saXN0aW5mby9pZXRmLWxhbmd1YWdlcyIgdGFy Z2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2 ZW50LHRoaXMpIj5odHRwOi8vd3d3LmFsdmVzdHJhbmQubm8vbWFpbG1hbi9saXN0aW5mby9pZXRm LWxhbmd1YWdlczwvYT48L3NwYW4+PC9mb250PjwvcD4KCjwvZGl2PgoKPHA+PGZvbnQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+ PGJyPgo8YnIgY2xlYXI9ImFsbCI+Cjxicj4KLS0gPGJyPgpNYXJrIDwvc3Bhbj48L2ZvbnQ+PC9w PgoKPC9zcGFuPjwvZGl2PjwvZGl2PgoKPC9kaXY+Cgo8L2Rpdj4KCgo8YnI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+THRydSBtYWlsaW5nIGxpc3Q8 YnI+PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhp cykiIGhyZWY9Im1haWx0bzpMdHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnPC9hPjxicj48YSBv bmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgaHJl Zj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydSIgdGFyZ2V0PSJf YmxhbmsiPgpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1PC9hPjxi cj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj5N YXJrCg== ------=_Part_10591_4702298.1171578859767-- --===============0864276221== 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 --===============0864276221==-- From ltru-bounces@ietf.org Thu Feb 15 18:39:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHqBx-0004GI-Ay; Thu, 15 Feb 2007 18:39:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHqBw-0004FM-Jl for ltru@ietf.org; Thu, 15 Feb 2007 18:39:08 -0500 Received: from netc-relay-1m.netcourrier.com ([194.158.104.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHqBr-0000t5-4l for ltru@ietf.org; Thu, 15 Feb 2007 18:39:08 -0500 Received: from netcourrier.com (netcourrier-3m.netcourrier.com [194.158.104.103]) by netc-relay-1m.netcourrier.com (Postfix) with SMTP id 36C0A38BC7 for ; Fri, 16 Feb 2007 00:38:48 +0100 (CET) Received: from [85.68.10.110] by netcourrier-3m.netcourrier.com via html interface From: Nicolas Krebs To: ltru@ietf.org Date: Fri, 16 Feb 2007 00:38:48 +0100 Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Subject: [Ltru] Comorian and other issues X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org After partial review of urn:ietf:id:draft-ietf-ltru-4645bis-01 ( http://tools.ietf.org/html/draft-ietf-ltru-4645bis-01 ), i found some is= sue, = a question and our old friend -western. = 1 Persian What are the differences between fa-pes (Western Farsi) and fa-ir? between= = fa-prs (Eastern Farsi) and fa-af? = 2 western variant For =22western=22 generic variant previously discuted = ( http://www.alvestrand.no/pipermail/ietf-languages/2006-August/004899.htm= l = etc. ), you can see = fa-pes (Western Farsi) fa-prs (Eastern Farsi) hy-arevmda (Western Armenian) hy-arevela (Eastern Armenian) 3 Comorian % Type: language Subtag: swb Description: Comorian Added: 2008-01-01 %% Type: language Subtag: wlc Description: Mwali Comorian Description: Comorian, Mwali Added: 2008-01-01 %% Type: language Subtag: wni Description: Ndzwani Comorian Description: Comorian, Ndzwani Added: 2008-01-01 %% Type: language Subtag: zdj Description: Ngazidja Comorian Description: Comorian, Ngazidja Added: 2008-01-01 %% If i understand correctly, swb is the encompass language, and the other ar= e dialect. Then: = %% Type: extlang Subtag: wlc Description: Mwali Comorian Description: Comorian, Mwali Added: 2008-01-01 Prefix: swb %% Type: extlang Subtag: wni Description: Ndzwani Comorian Description: Comorian, Ndzwani Added: 2008-01-01 Prefix: swb %% Type: extlang Subtag: zdj Description: Ngazidja Comorian Description: Comorian, Ngazidja Added: 2008-01-01 Prefix: swb %% 4 =22specific=22 = Are the follwing subtag enough unambiguous and defined? = Should their Description be modified such Goanese Konkani = or Cocos Islands Malay? = %% Type: language Subtag: zne Description: Zande (specific) Added: 2008-01-01 %% Type: extlang Subtag: dgo Description: Dogri (specific) Added: 2008-01-01 Prefix: doi %% Type: extlang Subtag: knn Description: Konkani (specific) Added: 2008-01-01 Prefix: kok %% Type: extlang Subtag: mly Description: Malay (specific) Added: 2008-01-01 Prefix: ms %% Type: extlang Subtag: swh Description: Swahili (specific) Added: 2008-01-01 Prefix: sw %% It would done %% Type: extlang Subtag: swh Description: Swahili (specific) Description: Swahili, Tanzania Added: 2008-01-01 Prefix: sw %% 5 modified Description = For the following sutag, the Description: was modified, and so the meaning= too. = %% Type: language Subtag: fy Description: Western Frisian Description: Frisian, Western Added: 2005-10-16 %% Type: language Subtag: km Description: Central Khmer Description: Khmer, Central Added: 2005-10-16 Suppress-Script: Khmr %% Type: language Subtag: rm Description: Romansh Added: 2005-10-16 %% IMHO, should be supercedes by = %% Type: language Subtag: fy Description: Frisian Added: 2005-10-16 Deprecated: 2005-11-16 %% Type: language Subtag: km Description: Khmer Added: 2005-10-16 Deprecated: 2006-10-27 Suppress-Script: Khmr %% Type: language Subtag: rm Description: Raeto-Romance Added: 2005-10-16 Deprecated: 2006-10-25 %% Type: language Subtag: fy Description: Western Frisian Description: Frisian, Western Added: 2005-11-16 %% Type: language Subtag: km Description: Central Khmer Description: Khmer, Central Added: 2006-10-27 Suppress-Script: Khmr %% Type: language Subtag: rm Description: Romansh Added: 2006-10-25 %% _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Feb 16 02:19:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHxNK-0008El-SB; Fri, 16 Feb 2007 02:19:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHxNJ-00087x-C6 for ltru@ietf.org; Fri, 16 Feb 2007 02:19:21 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHxNI-0004Gk-0m for ltru@ietf.org; Fri, 16 Feb 2007 02:19:21 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HHxNH-0004Qp-Dd; Fri, 16 Feb 2007 02:19:19 -0500 Date: Fri, 16 Feb 2007 02:19:19 -0500 To: Nicolas Krebs Subject: Re: [Ltru] Comorian and other issues Message-ID: <20070216071919.GF31388@mercury.ccil.org> References: 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: c3a18ef96977fc9bcc21a621cbf1174b 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 Nicolas Krebs scripsit: > After partial review of urn:ietf:id:draft-ietf-ltru-4645bis-01 ( > http://tools.ietf.org/html/draft-ietf-ltru-4645bis-01 ), i found some > issue, a question and our old friend -western. Generic note: These considerations are appropriate for the ISO 693-3 Registration Authority, not for ietf-languages; we just clone what they provide. My comments are not authoritative. > 1 Persian > What are the differences between fa-pes (Western Farsi) and fa-ir? between > fa-prs (Eastern Farsi) and fa-af? By what I understand, the written forms in Iran and Afghanistan are very similar, the spoken versions (Farsi and Dari) not so much. So fa-ir and fa-af would suggest the slightly different written forms, whereas fa-prs and fa-pes would suggest the rather more divergent spoken varieties. This is not a necessary implication, just what a bit of desultory research suggests to me. > 2 western variant > For "western" generic variant previously discuted > ( http://www.alvestrand.no/pipermail/ietf-languages/2006-August/004899.html > etc. ), you can see > fa-pes (Western Farsi) > fa-prs (Eastern Farsi) > hy-arevmda (Western Armenian) > hy-arevela (Eastern Armenian) In 639-3, the two varieties of Farsi are different enough to count as separate languages, whereas the two varieties of Armenian are not. > 3 Comorian [snip] > If i understand correctly, swb is the encompass language, and the > other are dialect. Then: That's not the view of 639-3, which treats the four as separate and distinct languages. Comorian (swb) is the largest, but it's not considered to encompass the others. > 4 "specific" > Are the follwing subtag enough unambiguous and defined? Again, we are tracking the names chosen by 639-3. The point of "(specific)" is to deal with cases where a macrolanguage and one of the encompassed languages have the same name. > 5 modified Description > For the following sutag, the Description: was modified, and so the > meaning too. > > %% > Type: language > Subtag: fy > Description: Western Frisian > Description: Frisian, Western > Added: 2005-10-16 [snip] > Type: language > Subtag: fy > Description: Frisian > Added: 2005-10-16 > Deprecated: 2005-11-16 > %% > Type: language > Subtag: fy > Description: Western Frisian > Description: Frisian, Western > Added: 2005-11-16 Descriptions are non-normative for us (though we get them from ISO standards where they are normative), so we don't deprecate and then reinstate a subtag for the sake of a description. Indeed, once a subtag is deprecated, it stays deprecated forever. -- John Cowan cowan@ccil.org http://ccil.org/~cowan If a traveler were informed that such a man [as Lord John Russell] was leader of the House of Commons, he may well begin to comprehend how the Egyptians worshiped an insect. --Benjamin Disraeli _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Feb 16 04:38:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHzXz-0007Gc-Vg; Fri, 16 Feb 2007 04:38:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHzXy-0007Fw-0z for ltru@ietf.org; Fri, 16 Feb 2007 04:38:30 -0500 Received: from smtp1.wsfo.org ([208.145.81.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHzXt-0008KY-EU for ltru@ietf.org; Fri, 16 Feb 2007 04:38:30 -0500 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp1.wsfo.org (8.13.1/8.13.1) with ESMTP id l1G9cIpC018139 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 16 Feb 2007 04:38:18 -0500 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.51 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.150.139.69] (account martin_hosken@sil.org HELO [192.168.1.3]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 136803636 for ltru@ietf.org; Fri, 16 Feb 2007 04:38:18 -0500 Message-ID: <45D57B86.7000003@sil.org> Date: Fri, 16 Feb 2007 16:38:14 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: LTRU Working Group X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ltru] Identifying script (or global) variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear All, In my unstinting desire to be able to separate out script and language from a language tag, it would be really nice if there was some non-semantic mechanism by which a variant that is being used to modify a script (and therefore has no constraining language in its specification) may be identified over a language specific variant (which may be to do with script, but is langauge specific). There are numerous ways this could be done, for example by restricting them to start with a specific letter or letters, or somesuch. Whichever way that may result I see no problem in having to change standards since it is merely a constraint on variant naming that can be added to the standard after the fact if necessary. No change to the regexp or anything that has gone before. Is there any hope that I may be able to write code that can truly separate language and script on this basis or should I give up now and resign myself to having to track the latest repository and rerelease my code every so often to reflect that? Yours, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Feb 16 04:55:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHzoA-0003GA-M4; Fri, 16 Feb 2007 04:55:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHzo9-0003Fj-89 for ltru@ietf.org; Fri, 16 Feb 2007 04:55:13 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHzm0-0004Ta-BO for ltru@ietf.org; Fri, 16 Feb 2007 04:53:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 7E5A826C2C0; Fri, 16 Feb 2007 10:52:39 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id DB57026C1A7; Fri, 16 Feb 2007 10:52:38 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id D87DB58ECE7; Fri, 16 Feb 2007 10:52:38 +0100 (CET) Date: Fri, 16 Feb 2007 10:52:38 +0100 From: Stephane Bortzmeyer To: Martin Hosken Message-ID: <20070216095238.GA6065@nic.fr> References: <45D57B86.7000003@sil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45D57B86.7000003@sil.org> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: LTRU Working Group Subject: [Ltru] Re: Identifying script (or global) variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Feb 16, 2007 at 04:38:14PM +0700, Martin Hosken wrote a message of 28 lines which said: > it would be really nice if there was some non-semantic mechanism by > which a variant that is being used to modify a script (and therefore > has no constraining language in its specification) may be identified > over a language specific variant (which may be to do with script, > but is langauge specific). I have no idea right now but can you provide more specific examples, in order to gain a better understanding of the problem? > There are numerous ways this could be done, for example by > restricting them to start with a specific letter or letters, or > somesuch. In the future 4646bis registry, there are only twelve variants, eight seem to be related to the spoken language and two (the ones with digits) related to the orthography (and so language-specific). Only the remaining two, the famous fonipa and fonupa seem language-independant. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Feb 16 10:10:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4jE-0005mJ-WD; Fri, 16 Feb 2007 10:10:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4jD-0005m9-28 for ltru@ietf.org; Fri, 16 Feb 2007 10:10:27 -0500 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI4jA-0005iQ-Uk for ltru@ietf.org; Fri, 16 Feb 2007 10:10:27 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070216151020.LBJI14346.mta13.adelphia.net@DGBP7M81> for ; Fri, 16 Feb 2007 10:10:20 -0500 Message-ID: <00c801c751dc$9298f060$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 16 Feb 2007 07:10:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Ltru] Re: Comorian and other issues X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Nicolas Krebs wrote: > 2 western variant > For "western" generic variant previously discuted > ( > http://www.alvestrand.no/pipermail/ietf-languages/2006-August/004899.html > etc. ), you can see > fa-pes (Western Farsi) > fa-prs (Eastern Farsi) > hy-arevmda (Western Armenian) > hy-arevela (Eastern Armenian) As you can see from looking at the Registry, the "'western' generic variant" didn't materialize. It was deemed too broad, and so instead we have "arevmda" and "arevela" which apply specifically to Armenian. "Western" and "Eastern" mean very different things depending on the language those words modify. > 5 modified Description > For the following sutag, the Description: was modified, and so the > meaning too. When an ISO agency changes the Description but keeps the same code element, they are expressing their view that the entity being coded is the same. We reflect that view in standards-based subtags. -- 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 Feb 16 10:21:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4tO-0004n1-L0; Fri, 16 Feb 2007 10:20:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4tN-0004mw-8E for ltru@ietf.org; Fri, 16 Feb 2007 10:20:57 -0500 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI4tI-0007nb-SD for ltru@ietf.org; Fri, 16 Feb 2007 10:20:57 -0500 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.685.24; Fri, 16 Feb 2007 07:20:52 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Fri, 16 Feb 2007 07:20:51 -0800 From: Peter Constable To: Mark Davis Date: Fri, 16 Feb 2007 07:20:41 -0800 Subject: RE: [Ltru] Re: Ietf-languages Digest, Vol 50, Issue 15 Thread-Topic: [Ltru] Re: Ietf-languages Digest, Vol 50, Issue 15 Thread-Index: AcdRUnGd67oy61IuQWC4nue8J5MZ7gAikvSg Message-ID: References: <20070215082323.hiiu4xvtes8wogww@webmail0.linguistlist.org> <30b660a20702150855r11fff871se2cddb412f87169e@mail.gmail.com> <30b660a20702151434p439c1455pa651bb03acf64269@mail.gmail.com> In-Reply-To: <30b660a20702151434p439c1455pa651bb03acf64269@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 33fc46667f70a87403df4cb21ee8343c Cc: LTRU Working Group , "ietf-languages@alvestrand.no" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1985929358==" Errors-To: ltru-bounces@ietf.org --===============1985929358== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB835795557E146BE7NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB835795557E146BE7NAEXMSGC117re_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable The JAC has various issues I need to get them to review. I will include thi= s among them. There's one scenario I think is of interest: Suppose there are currently on= ly a handful of documents in non-modern Czech (I don't know what the actual= situation is) - not enough that anyone feels a particular need to request = separate IDs for historical forms. What then? Well, I guess they would use = "ces"; that's a little like someone wondering if a letterform is a distinct= character and deciding to treat it like a font variant and not requesting = a new character in Unicode/ISO 10646. But then suppose later someone discov= ers some lost library of Old and Middle Czech documents. What then? At that= point, they'd probably request separate IDs for the historical form, and t= hey might argue that this is splitting the historical variants from the sin= gle category - i.e. that would mean a new ID for the modern language and we= ll as the historical languages, and "ces" would automatically become a macr= olanguage. Of course, the scenario playing out that way depends on users initially dec= iding to use "ces" for the historical records and not requesting separate I= Ds, and on the JAC deciding that there was established usage of "ces" for m= ultiple variants. (By analogy, UTC wouldn't necessarily decide that the exi= sting character was ambiguous and that *two* new, unambiguous characters ar= e needed.) Peter ________________________________ From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On B= ehalf Of Mark Davis Sent: Thursday, February 15, 2007 2:34 PM To: Peter Constable Cc: LTRU Working Group; ietf-languages@alvestrand.no Subject: Re: [Ltru] Re: Ietf-languages Digest, Vol 50, Issue 15 I'm inclined towards #2 also, for the reasons you cite. My primary concern,= however, is to get a definitive statement from the RA as to which of the p= olicies is true. That, for me, is far more important than which policy is a= ctually used. Mark On 2/15/07, Peter Constable > wrote: Adopting 1 would mean adopting generally across all of ISO 639-3: all entri= es of individual-language scope encompass corresponding historic varieties.= But then, note that historic varieties are relevant only in cases of langu= ages with a long literary tradition that is preserved. For instance, there = may have been an old Naskapi that is distinct from the modern descendent, b= ut there never have been and never will be any records in this putative lan= guage, so there is zero need for an identifier that encompasses it. (Btw, please note: we do *not* code reconstructed protolanguages. ISO 639-3= is explicit about that. So please don't anybody suggest we'd be coding pro= to-Naskapi.) So really we're just talking about some limited set of cases with a literar= y tradition. Note that we're also only talking about cases in which languages were well-= enough developed to maintain a single identify over several hundred years. = That's what distinguishes a "historic" language from an "extinct" language.= For instance, there are historic documents in a pre-Columbian Mixtec varie= ty, but that language identity is not preserved by one specific modern Mixt= ec variety. And I reject the notion that pre-Columbian Mixtec together with= all the modern Mixtec varieties is a macrolanguage unless someone makes th= e case that there's a user scenario in which it is appropriate to treat all= those varieties as one language. So the number of relevant cases is fairly constrained. I don't know just ho= w many there would be, but it's going to be a small fraction of all modern = languages for which this is relevant. I have a concern with 1 that it would detract from interoperability, for th= e kinds of reasons Anthony mentions. There is a very large amount of usage = in which "eng" is intended to mean specifically modern English, and a very = large amount of usage in which "ces" is intended to mean specifically moder= n Czech. I don't see who it would help to decide that these IDs encompass O= ld English and Old Czech respectively: the average modern-language user isn= 't likely going to be cataloguing content in Old English and Old Czech, and= they certainly aren't going to be helped by having queries return records = in the historic varieties. As for the specialist, they certainly don't want= to catalog content as all "eng" and "ces", as Anthony has made clear. The = only scenario in which maybe someone is helped is when the specialist wants= a query to return records for all historic varieties. I don't see why they= can't use a Boolean operator for that, but even if there was enough need f= or a single ID, I wouldn't be inclined to use "eng' and "ces" for that purp= ose: that would be helping the 0.01% scenario at the detriment of 99.99% of= users. Thus, I'm inclined towards 2. There is certainly willingness in general on = the part of the ISO 639 JAC to code historic languages, so I have no doubt = that IDs for things like Old Czech etc. would be provided so long as the ne= ed is clear and there's a sense that the historic boundaries deemed appropr= iate by philologists, research librarians, etc. are appropriate. Peter ________________________________ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Thursday, February 15, 2007 8:55 AM To: Anthony Aristar Cc: LTRU Working Group; ietf-languages@alvestrand.no Subject: [Ltru] Re: Ietf-languages Digest, Vol 50, Issue 15 Your quotation below omits the true author, and may leave the impression th= at I wrote a number of paragraphs that I do not agree with and did not writ= e. I only wrote "Assume that old Czech ..." -- someone else wrote the "But = is this a real problem...." > Mark Davis wrote: > > > Assume that old Czech is as different from modern as fro is from fr. > > But is this a real problem? How much total literature is written ... That being said, there are two models that ISO could be using. 1. Overlapping. 'eng' means any English, modern or historic. 'ang' means = specifically Old English, a subset of 'eng'. 'ces' means any Czech. There i= s no tag specifically for Old Czech. * so I could tag Beowulf with 'ang' or 'eng', but Shakespeare, Austen= , and Robin Williams only with 'eng'. * Smil Fla=B9ka z Pardubic and V=E1clav Havel are both tagged with 'c= es'. * Requests for BCP 47 variant tags for Shakespearean English (en-SHAK= ESPR) or old Czech (cs-OLDCZECH) would be legitimate. * A request for a variant tag for only modern English (en-MODENGL), t= hus excluding Old English, would be legitimate. 1. Disjoint. 'eng' means only modern English, 'ang' means Old English, 'c= es' means only modern Czech. There is no tag at all (currently) for Old Cze= ch. * so I could tag Beowulf with 'ang' only. * and there is no valid current code for tagging for Smil Fla=B9ka z = Pardubic * A request for BCP 47 variant tags for Shakespearean English (en-SHA= KESPR) would be legitimate * A request for a registered old Czech language tag (oldczech) would = be legitimate. (However "primary languages are strongly RECOMMENDED for reg= istration with ISO 639, and proposals rejected by ISO 639/RA will be closel= y scrutinized before they are registered with IANA." ) I don't think they are using model number one, but we need to find out. Mark On 2/15/07, Anthony Aristar < aristar@linguistlist.org> wrote: With all due respect, this seems like a very odd discussion from my perspective as a linguistics professor. The discussion seems to presuppose that all that matters is whether Microsoft is going to one day produce a version of Word in Middle High German or Old English, or how many texts exist in a language. But the ISO 639 codes are used for much more than this. In particular, they are used to ensure interoperability, allowing material of the same linguistic nature to be found in searches, and to be compared using the linguistic ontologies that are now being developed. If I am a scholar searching for texts in Old English (or Old High German, for that matter) and everyone has been cavalier enough to code such material with eng and deu, what the search engines return will be utterly useless to me. I am going to be flooded with such a quantity of material in Modern English and Modern German that searching through it will be essentially impossible. So if you really believe that it doesn't matter if you code English material as eng, whatever its period, what you're really saying is that you don't really care about interoperability, and that you don't really care about scholarship. ************************************** Anthony Aristar, Director, Institute for Language Information & Technology Professor of Linguistics Moderator, LINGUIST Principal Investigator, EMELD Project Linguistics Program Dept. of English aristar@linguistlist.org Eastern Michigan University 2000 Huron River Dr, Suite 104 Ypsilanti, MI 48197 U.S.A. URL: http://linguistlist.org/aristar/ ************************************** > Mark Davis wrote: > > > Assume that old Czech is as different from modern as fro is from fr. > > But is this a real problem? How much total literature is written > and available in different variations of Czech? My prejudice says > that as a nation with a language and literature of its own, Czech > is about as young as Finnish, Norwegian or Serbian, i.e. 19th > century. Can you give any concrete examples when not having a > separate *code* for pre-renaissance Czech is a practical problem? > > Linguists of course have *names* for Swedish of all ages, but I > see no real use for having ISO or the IETF specify language > *codes*. I could be wrong, but if so please enlighten and correct > me. Nobody is going to translate OpenOffice or Mozilla to the > language spoken by vikings (Old Norse) or the Swedish used during > the Lutheran reformation (called New Swedish, ironically). > > Yes, there is now a branch of Wikipedia in Old English > ( ang.wikipedia.org), but that is a rare except= ion. I don't expect > this to happen in other languages. Ang has now 744 articles, > compared to the 11,000 articles of the Latin Wikipedia. _______________________________________________ Ietf-languages mailing list Ietf-languages@alvestrand.no http://www.alvestrand.no/mailman/listinfo/ietf-languages -- Mark _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- Mark --_000_DDB6DE6E9D27DD478AE6D1BBBB835795557E146BE7NAEXMSGC117re_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

The JAC has various issues I need to g= et them to review. I will include this among them.

 

There’s one scenario I think is = of interest: Suppose there are currently only a handful of documents in non-mo= dern Czech (I don’t know what the actual situation is) – not enough = that anyone feels a particular need to request separate IDs for historical forms. What then? Well, I guess they would use “ces”; that’s a little= like someone wondering if a letterform is a distinct character and deciding to treat it = like a font variant and not requesting a new character in Unicode/ISO 10646. But then suppose later someone discovers some lost library of Old and Middle Cz= ech documents. What then? At that point, they’d probably request separate= IDs for the historical form, and they might argue that this is splitting the histor= ical variants from the single category – i.e. that would mean a new ID for= the modern language and well as the historical languages, and “ces” would = automatically become a macrolanguage.

 

Of course, the scenario playing out th= at way depends on users initially deciding to use “ces” for the hi= storical records and not requesting separate IDs, and on the JAC deciding that there was established usage of “ces” for multiple variants. (By analogy, = UTC wouldn’t necessarily decide that the existing character was ambiguous and that *<= span style=3D'font-weight:bold'>two* new, unambiguous characters are needed.)

 

 

Peter

 

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Behalf Of Mark Davis
Sent: Thursday, February 15,= 2007 2:34 PM
To: Peter Constable
Cc: LTRU Working Group; ietf-languages@alvestrand.no
Subject: Re: [Ltru] Re: Ietf-languages Digest, Vol 50, Issue 15

 

I'm inclined towa= rds #2 also, for the reasons you cite. My primary concern, however, is to get a definitive statement from the RA as to which of the policies is true. That,= for me, is far more important than which policy is actually used.

Mark

On 2/15/07, Peter Constable <= ;petercon@microsoft.com> wrote= :

Adopting 1 would mean adopting generally across all of IS= O 639-3: all entries of individual-language scope encompass corresponding historic varieties. But then, note that historic varieties are relevant onl= y in cases of languages with a long literary tradition that is preserved. For in= stance, there may have been an old Naskapi that is distinct from the modern descend= ent, but there never have been and never will be any records in this putative language, so there is zero need for an identifier that encompasses it.

 

(Btw, please note: we do *not* code reconstructed protolanguages. ISO 639-3 is explicit about that. So ple= ase don't anybody suggest we'd be coding proto-Naskapi.)

 

So really we're just talking about some limited set of ca= ses with a literary tradition.

 

Note that we're also only talking about cases in which languages were well-enough developed to maintain a single identify over sev= eral hundred years. That's what distinguishes a "historic" language fr= om an "extinct" language. For instance, there are historic documents= in a pre-Columbian Mixtec variety, but that language identity is not preserved= by one specific modern Mixtec variety. And I reject the notion that pre-Columb= ian Mixtec together with all the modern Mixtec varieties is a macrolanguage unl= ess someone makes the case that there's a user scenario in which it is appropri= ate to treat all those varieties as one language.

 

So the number of relevant cases is fairly constrained. I don't know just how many there would be, but it's going to be a small fract= ion of all modern languages for which this is relevant.

 

I have a concern with 1 that it would detract from interoperability, for the kinds of reasons Anthony mentions. There is a ver= y large amount of usage in which "eng" is intended to mean specific= ally modern English, and a very large amount of usage in which "ces" i= s intended to mean specifically modern Czech. I don't see who it would help t= o decide that these IDs encompass Old English and Old Czech respectively: the average modern-language user isn't likely going to be cataloguing content i= n Old English and Old Czech, and they certainly aren't going to be helped by having queries return records in the historic varieties. As for the special= ist, they certainly don't want to catalog content as all "eng" and "ces", as Anthony has made clear. The only scenario in which mayb= e someone is helped is when the specialist wants a query to return records fo= r all historic varieties. I don't see why they can't use a Boolean operator f= or that, but even if there was enough need for a single ID, I wouldn't be incl= ined to use "eng' and "ces" for that purpose: that would be helpi= ng the 0.01% scenario at the detriment of 99.99% of users.<= /o:p>

 

Thus, I'm inclined towards 2. There is certainly willingn= ess in general on the part of the ISO 639 JAC to code historic languages, so I = have no doubt that IDs for things like Old Czech etc. would be provided so long = as the need is clear and there's a sense that the historic boundaries deemed a= ppropriate by philologists, research librarians, etc. are appropriate.

 

 

 

Peter

 

 

From: Mark Davis [mailto:mark.davis@icu= -project.org]
Sent: Thursday, February 15,= 2007 8:55 AM
To: Anthony Aristar
Cc: LTRU Working Group; ietf-languag= es@alvestrand.no
Subject: [Ltru] Re: Ietf-lan= guages Digest, Vol 50, Issue 15

 

Your quotation below omits the true author, and may leave the impression that I wrote a number of paragraphs that I do not agree with and did not write. I = only wrote "Assume that old Czech ..." -- someone else wrote the "= ;But is this a real problem...."

> Mark Davis wrote:
>
> > Assume that old Czech is as different from modern as fro is from = fr.
>
> But is this a real problem?  How much total literature is written
...

That being said, there are two models that ISO could be using. <= /span>

  1. Overlapping. 'eng' means any English, modern or historic. 'ang' means specifically Old En= glish, a subset of 'eng'. 'ces' means any Czech. There is no tag specifically= for Old Czech.
    1. so I could tag Beowulf with 'ang' or 'eng'= , but Shakespeare, Austen, and Robin Williams only with 'eng'.
    2. Smil Fla=B9ka z Pardubic and V=E1clav Have= l are both tagged with 'ces'.
    3. Requests for BCP 47 variant tags for Shakespearean English (en-SHAKESPR) or old Czech (cs-OLDCZECH) would = be legitimate.
    4. A request for a variant tag for only moder= n English (en-MODENGL), thus excluding Old English, would be legitimate= .
  1. Disjoint. 'eng' means only modern English, 'ang' means Old English, 'ces' means only modern Czech. There is no tag at all (currently) for Old Czech.
    1. so I could tag Beowulf with 'ang' only.
    2. and there is no valid current code for tag= ging for Smil Fla=B9ka z Pardubic
    3. A request for BCP 47 variant tags for Shakespearean English (en-SHAKESPR) would be legitimate
    4. A request for a registered old Czech langu= age tag (oldczech) would be legitimate. (However "primary languages = are strongly RECOMMENDED for registration with ISO 639, and proposals rejected by ISO 639/RA will be closely scrutinized before they are registered with IANA." )

<= span style=3D'font-size:12.0pt'>I don't think they are using model number one, b= ut we need to find out.

Mark

On 2/15/07, Anthony Aristar <= ; aristar@linguistlist.org> wrote:

With all due respect, this seems like a very odd discussion from my
perspective  as a linguistics professor.  The discussio= n seems to
presuppose that all that matters is whether Microsoft is going to one
day produce a version of Word in Middle High German or Old English, or
how many texts exist in a language.

But the ISO 639 codes are used for much more than this.  In particular,
they are used to ensure interoperability, allowing material of the same
linguistic nature to be found in searches, and to be compared using the linguistic ontologies that are now being developed.  If I am a scholar
searching for texts in Old English (or Old High German, for that
matter) and everyone has been cavalier enough to code such material
with eng and deu, what the search engines return will be utterly
useless to me.  I am going to be flooded with such a quantity of<= br> material in Modern English and Modern German that searching through it
will be essentially impossible.

So if you really believe that it doesn't matter if you code English
material as eng, whatever its period, what you're really saying is that
you don't really care about interoperability, and that you don't really
care about scholarship.

            &nb= sp;   **************************************
Anthony Aristar, Director, Institute for Language Information & Technol= ogy
            &nb= sp;      Professor of Linguistics
Moderator, LINGUIST           &= nbsp;   Principal Investigator, EMELD Project
Linguistics Program
Dept. of English           &n= bsp;      aristar@linguist= list.org
Eastern Michigan University           = ; 2000 Huron River Dr, Suite 104
Ypsilanti, MI 48197
U.S.A.

URL: http://= linguistlist.org/aristar/
            &nb= sp;   **************************************

> Mark Davis wrote:
>
> > Assume that old Czech is as different from modern as fro is from = fr.
>
> But is this a real problem?  How much total literature is written
> and available in different variations of Czech?  My prejudic= e says
> that as a nation with a language and literature of its own, Czech
> is about as young as Finnish, Norwegian or Serbian, i.e. 19th
> century.  Can you give any concrete examples when not having= a
> separate *code* for pre-renaissance Czech is a practical problem?
>
> Linguists of course have *names* for Swedish of all ages, but I
> see no real use for having ISO or the IETF specify language
> *codes*.  I could be wrong, but if so please enlighten and correct
> me.  Nobody is going to translate OpenOffice or Mozilla to t= he
> language spoken by vikings (Old Norse) or the Swedish used during
> the Lutheran reformation (called New Swedish, ironically).
>
> Yes, there is now a branch of Wikipedia in Old English
> ( ang.wikipedia= .org), but that is a rare exception.  I don't expect
> this to happen in other languages.  Ang has now 744 articles= ,
> compared to the 11,000 articles of the Latin Wikipedia.





_______________________________________________
Ietf-languages mailing list
Ietf-lang= uages@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages<= /a>




--
Mark


_______________________________________________
Ltru mailing list
Ltru@ietf.org
h= ttps://www1.ietf.org/mailman/listinfo/ltru




--
Mark

--_000_DDB6DE6E9D27DD478AE6D1BBBB835795557E146BE7NAEXMSGC117re_-- --===============1985929358== 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 --===============1985929358==-- From ltru-bounces@ietf.org Sat Feb 17 01:51:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIJPO-0005QN-Qq; Sat, 17 Feb 2007 01:50:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIJPO-0005QI-C7 for ltru@ietf.org; Sat, 17 Feb 2007 01:50:58 -0500 Received: from smtp1.wsfo.org ([208.145.81.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIJPN-0001NR-43 for ltru@ietf.org; Sat, 17 Feb 2007 01:50:58 -0500 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp1.wsfo.org (8.13.1/8.13.1) with ESMTP id l1H6oqpQ018130 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Sat, 17 Feb 2007 01:50:52 -0500 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.51 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.150.139.69] (account martin_hosken@sil.org HELO [192.168.1.3]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 136884362; Sat, 17 Feb 2007 01:50:51 -0500 Message-ID: <45D6A5C5.2070105@sil.org> Date: Sat, 17 Feb 2007 13:50:45 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <45D57B86.7000003@sil.org> <20070216095238.GA6065@nic.fr> In-Reply-To: <20070216095238.GA6065@nic.fr> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: LTRU Working Group Subject: [Ltru] Re: Identifying script (or global) variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear Stephane, > >> it would be really nice if there was some non-semantic mechanism by >> which a variant that is being used to modify a script (and therefore >> has no constraining language in its specification) may be identified >> over a language specific variant (which may be to do with script, >> but is langauge specific). >> > > I have no idea right now but can you provide more specific examples, > in order to gain a better understanding of the problem? > Consider a generic lexical database in which one knows the script of fields but not necessarily the vernacular language being described. I.e. the vernacular language is itself a value in the database. One wants to be able to take that language and the script information and create a language tag. So being able to parse a tag for script (including variants) is key. In addition, very often rendering is based on script independently of language (who cares what language, but IPA will always be rendered using, say Doulos SIL). > In the future 4646bis registry, there are only twelve variants, eight > seem to be related to the spoken language and two (the ones with > digits) related to the orthography (and so language-specific). > > Only the remaining two, the famous fonipa and fonupa seem > language-independant. > Exactly. If we could keep the language-independent script variants to all start with 'fon' that would be great. Much easier than having to update a registry of them each time a new one is added. The hassle of tracking the standard to watch for when such things are added must be considered. Yours, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Feb 17 10:24:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIRPv-0000Ro-I7; Sat, 17 Feb 2007 10:24:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIRPt-0000Qx-VG for ltru@lists.ietf.org; Sat, 17 Feb 2007 10:24:01 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIRPo-0000tW-Lu for ltru@lists.ietf.org; Sat, 17 Feb 2007 10:24:01 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HIRPi-00060H-R5 for ltru@lists.ietf.org; Sat, 17 Feb 2007 16:23:50 +0100 Received: from 212.82.251.177 ([212.82.251.177]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 17 Feb 2007 16:23:50 +0100 Received: from nobody by 212.82.251.177 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 17 Feb 2007 16:23:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 17 Feb 2007 16:23:09 +0100 Organization: Lines: 12 Message-ID: <45D71DDD.15D5@xyzzy.claranet.de> References: <002501c75011$ad023e60$6401a8c0@DGBP7M81> <20070214130638.GA21542@nic.fr> <2711F304-8A45-4085-89C7-D176FDCBA55C@egt.ie> <20070214163549.GD19053@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.177 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: "Placeholder" dates in draft Regsitry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> Would such a placeholder as 6666-06-06, 7777-07-07 or 1111-11-11 >> break such systems, Stephane?:-) > Unfortunately, dates later than 2038 are hard for many systems to > handle. Then it's a good test, like 2106-02-08... Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Feb 17 13:31:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIULY-0002Rs-C8; Sat, 17 Feb 2007 13:31:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIULX-0002Rn-UI for ltru@ietf.org; Sat, 17 Feb 2007 13:31:43 -0500 Received: from mta19.mail.adelphia.net ([68.168.78.226] helo=mta19.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIULW-0006pr-Iz for ltru@ietf.org; Sat, 17 Feb 2007 13:31:43 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070217182714.OOTX22452.mta10.adelphia.net@DGBP7M81> for ; Sat, 17 Feb 2007 13:27:14 -0500 Message-ID: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 17 Feb 2007 10:27:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Ltru] Re: Identifying script (or global) variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Hosken wrote: > In my unstinting desire to be able to separate out script and language > from a language tag, it would be really nice if there was some > non-semantic mechanism by which a variant that is being used to modify > a script (and therefore has no constraining language in its > specification) may be identified over a language specific variant > (which may be to do with script, but is langauge specific). For reference, here's a brief summary of the existing variant subtags and the type of variation indicated by each. Difference in writing system (major): Language-independent: fonipa, fonupa Language-dependent: monoton, polyton Difference in orthography (minor): 1901, 1996 Dialect: arevela, arevmda. boont, nedis, rozaj, scouse Note that "major" and "minor" are intended to be vaguely descriptive, not value judgments. I considered the difference between "ß" and "ss" to be less major than the difference between traditional alphabets and purpose-built phonetic alphabets. I really, really don't want to reopen the question of whether IPA is a script! These categories may be merged, or divided along different lines. > There are numerous ways this could be done, for example by restricting > them to start with a specific letter or letters, or somesuch. > Whichever way that may result I see no problem in having to change > standards since it is merely a constraint on variant naming that can > be added to the standard after the fact if necessary. No change to the > regexp or anything that has gone before. I see two problems. First, it would be very difficult to assume that all future variants can be neatly boxed into one of these categories. It's possible that one dialect of a language is commonly used with one writing system or orthographic convention, and another is used with another, and for practical purposes the dialect issue and the writing-system issue cannot be separated. Second, we already have the 12 variants listed above, and in order to institute a syntactic distinction (assuming such is practical) we would have to deprecate at least some of them and replace them with new, conformant subtags. That brings with it the usual problem of deprecation—the old subtags still exist and must still be supported by software. > Is there any hope that I may be able to write code that can truly > separate language and script on this basis or should I give up now and > resign myself to having to track the latest repository and rerelease > my code every so often to reflect that? My opinion is that variants by their nature are a bit of a catch-all category, and it will always be necessary to update software to some extent to reflect changes in the Registry. You will need to do that anyway if you wish to make semantic use of the subtags (for example, switching to an IPA-enabled font upon seeing the "fonipa" subtag). -- 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 Feb 18 18:19:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIvIs-0005HL-RR; Sun, 18 Feb 2007 18:18:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIvIs-0005HG-IX for ltru@ietf.org; Sun, 18 Feb 2007 18:18:46 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIvIp-0005MA-ML for ltru@ietf.org; Sun, 18 Feb 2007 18:18:46 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l1INIUJa025832 for ; Mon, 19 Feb 2007 08:18:30 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4d56_5878d9a8_bfa6_11db_9e11_0014221fa3c9; Mon, 19 Feb 2007 08:18:30 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:46134) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 19 Feb 2007 08:17:34 +0900 Message-Id: <6.0.0.20.2.20070217161803.0ae45070@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 17 Feb 2007 16:23:50 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Progress In-Reply-To: <003801c74f79$88bc56f0$6401a8c0@DGBP7M81> References: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> <20070213100425.GA8824@nic.fr> <003801c74f79$88bc56f0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I think an artificial date is good, but I'd prefer to have one that look more artificial, e.g. 2099-01-01 or so (e.g. 2029-09-09 to address a point mentioned by John Cowan). Otherwise, some people might think that we plan to finish this work at the start of 2008, which would be terriby misleading. Regards, Martin. At 23:16 07/02/13, Doug Ewell wrote: >Stephane Bortzmeyer wrote: > >> The only thing that puzzles me is the: >> >> Added: 2008-01-01 >> >> for all the ISO 639-3 languages. I assume it should be replaced by the actual date of publication of 639-3? > >>From Section 2.1, "Starting Point": "The value of the File-Date field and of the Added date for each new subtag record are set to a date near the date of IESG approval of this memo. [RFC EDITOR NOTE: these dates would be updated during AUTH48.]" > >I've found that using a "real" date as a filler in this situation gets confusing. We are adding 7000 entries to a living Registry that is simultaneously undergoing its own changes, e.g. adding Meitei Mayak and Moon. Using an artificial date like 2008-01-01 clearly identifies the changes that are part of the bulk update. Ideally this date will be changed to the exact date of approval of the RFC. Last time around, the date of the final draft (2005-10-16) ended up enshrined as the "Added" date for everything in the Registry even though the RFC wasn't published until 11 months later. > >-- >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 >l > >_______________________________________________ >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 Mon Feb 19 07:51:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ7z9-0000dE-HZ; Mon, 19 Feb 2007 07:51:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ7z8-0000Yt-4p for ltru@ietf.org; Mon, 19 Feb 2007 07:51:14 -0500 Received: from mail14.svc.cra.dublin.eircom.net ([159.134.118.30]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJ7z5-00053u-SK for ltru@ietf.org; Mon, 19 Feb 2007 07:51:14 -0500 Received: (qmail 44430 messnum 5487467 invoked from network[194.125.174.102/ts09-102.dublin.indigo.ie]); 19 Feb 2007 12:51:02 -0000 Received: from ts09-102.dublin.indigo.ie (HELO ?194.125.174.102?) (194.125.174.102) by mail14.svc.cra.dublin.eircom.net (qp 44430) with SMTP; 19 Feb 2007 12:51:02 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <6.0.0.20.2.20070217161803.0ae45070@localhost> References: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> <20070213100425.GA8824@nic.fr> <003801c74f79$88bc56f0$6401a8c0@DGBP7M81> <6.0.0.20.2.20070217161803.0ae45070@localhost> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <3C67325D-7ABA-4219-9BB5-216D12AC48F6@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: Progress Date: Mon, 19 Feb 2007 12:53:29 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) 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 Thank you for that, Martin. That is precisely the point I was trying =20 to make, only put more clearly by you. However, this is not so =20 important, so I accept what has been decided already on that point. mg On 17 Feb 2007, at 07:23, scr=EDobh Martin Duerst: > I think an artificial date is good, but I'd prefer to have one > that look more artificial, e.g. 2099-01-01 or so (e.g. > 2029-09-09 to address a point mentioned by John Cowan). Otherwise, > some people might think that we plan to finish this work at > the start of 2008, which would be terriby misleading. - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Feb 19 16:55:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJGTN-0000E6-Pp; Mon, 19 Feb 2007 16:55:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJGTM-0000BD-T5 for ltru@ietf.org; Mon, 19 Feb 2007 16:55:00 -0500 Received: from mta13.adelphia.net ([68.168.78.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HJGTL-0004cL-FH for ltru@ietf.org; Mon, 19 Feb 2007 16:55:00 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070219215456.EQJP14346.mta13.adelphia.net@DGBP7M81> for ; Mon, 19 Feb 2007 16:54:56 -0500 Message-ID: <008201c75470$98773cd0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Subject: Re: [Ltru] Re: Progress Date: Mon, 19 Feb 2007 13:54:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > I think an artificial date is good, but I'd prefer to have one that > look more artificial, e.g. 2099-01-01 or so (e.g. 2029-09-09 to > address a point mentioned by John Cowan). Otherwise, some people might > think that we plan to finish this work at the start of 2008, which > would be terriby misleading. If nobody has any objections, I'll use 2029-09-09 in future drafts. I certainly hope we can finish by the start of 2008. The level of activity since I wrote the original "Progress" post 11 days ago has not been encouraging. There have been discussions about a variety of topics, but the only one I've seen that is related to moving 4646bis forward was from Mark, who said he still has outstanding issues with the draft and would send a list -- but I haven't seen the list yet. -- 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 Feb 19 17:07:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJGfS-0006L9-7i; Mon, 19 Feb 2007 17:07:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJGfR-0006L2-1l for ltru@lists.ietf.org; Mon, 19 Feb 2007 17:07:29 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJGfN-0007ZJ-ND for ltru@lists.ietf.org; Mon, 19 Feb 2007 17:07:29 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HJGdv-0004yn-Du for ltru@lists.ietf.org; Mon, 19 Feb 2007 23:05:55 +0100 Received: from 212.82.251.170 ([212.82.251.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Feb 2007 23:05:55 +0100 Received: from nobody by 212.82.251.170 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Feb 2007 23:05:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 19 Feb 2007 23:03:39 +0100 Organization: Lines: 14 Message-ID: <45DA1EBB.3DD9@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.170 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ltru] Erratum ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, thinking about John's I-D.klensin-unicode-escapes-02 my idea was to simply copy from RFC 4646: UNICHAR = "&#x" 2*6HEXDIG ";" BUT, it's wrong, isn't it ? I've now proposed this beast: UNICHAR = %x26.23.78 2*6HEXDIG ";" IOW ģ is fine, but ģ (X instead of x) is not, or is it ? See http://www.w3.org/TR/REC-xml/#sec-references Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Feb 19 20:54:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJKCW-0002z7-HH; Mon, 19 Feb 2007 20:53:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJKCV-0002yz-QN for ltru@ietf.org; Mon, 19 Feb 2007 20:53:51 -0500 Received: from smtp1.wsfo.org ([208.145.81.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJKCU-0006ZA-6k for ltru@ietf.org; Mon, 19 Feb 2007 20:53:51 -0500 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp1.wsfo.org (8.13.1/8.13.1) with ESMTP id l1K1rfwi016047 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Mon, 19 Feb 2007 20:53:41 -0500 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.51 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.150.136.250] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 137064373; Mon, 19 Feb 2007 20:53:40 -0500 Message-ID: <45DA54A0.3080007@sil.org> Date: Tue, 20 Feb 2007 08:53:36 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Identifying script (or global) variants References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> In-Reply-To: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp1.wsfo.org id l1K1rfwi016047 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Dear Doug, > For reference, here's a brief summary of the existing variant subtags > and the type of variation indicated by each. > > Difference in writing system (major): > Language-independent: fonipa, fonupa > Language-dependent: monoton, polyton > > Difference in orthography (minor): > 1901, 1996 > > Dialect: > arevela, arevmda. boont, nedis, rozaj, scouse Thanks for this list. Hmm. Yes I probably do need to include the language specific orthography/script variants, but not the dialect ones. > > Note that "major" and "minor" are intended to be vaguely descriptive, > not value judgments. I considered the difference between "=C3=9F" and > "ss" to be less major than the difference between traditional > alphabets and purpose-built phonetic alphabets. I really, really > don't want to reopen the question of whether IPA is a script! These > categories may be merged, or divided along different lines. Neither do I want to reopen that debate. But I do have some basic questions that I hope you can help with. Let's take the example of scouse English in IPA. How would I tag this? en-Latn-scouse-fonipa en-Latn-fonipa-scouse en-fonipa-scouse en-scouse-fonipa Now if I were to want to get hold of any scouse text in IPA, what should my RFC 4647 filter be? en-*-fonipa-scouse en-*-scouse-fonipa do I really need to have two filters for this? > My opinion is that variants by their nature are a bit of a catch-all > category, and it will always be necessary to update software to some > extent to reflect changes in the Registry. You will need to do that > anyway if you wish to make semantic use of the subtags (for example, > switching to an IPA-enabled font upon seeing the "fonipa" subtag). Given the number of orthography variants in languages around the world, I wonder what the best way to handle them all is. Do we (I'm thinking SIL with its involvement in so many languages and linguists with their test orthographies, etc.) need to submit every single one, or would it help you guys if we were to internally register them (perhaps using a singleton based extension) and then forward the interesting ones to you? Yours, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Feb 19 20:59:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJKHi-0005jC-MS; Mon, 19 Feb 2007 20:59:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJKHh-0005j4-2c for ltru@ietf.org; Mon, 19 Feb 2007 20:59:13 -0500 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJKHf-0007ZJ-Lw for ltru@ietf.org; Mon, 19 Feb 2007 20:59:13 -0500 Received: by wx-out-0506.google.com with SMTP id h31so1980255wxd for ; Mon, 19 Feb 2007 17:59:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=N8l8LVaXxwWElf4V7AzMw2GMhaMaOaeePPXOOq1WVWWE2UPnTITlzX8WfcF0NLYGMit3JoLPS6F/T42ttDsDe5jDo7p6CFiLKjAIy2FNaVTvl1VvuiYKJ2dLbtlI03pnGHHXOsuqiWEu3EGJpi6Cmty7XEXU5pxTiuSPF/eMqD8= Received: by 10.90.55.19 with SMTP id d19mr8040934aga.1171936751374; Mon, 19 Feb 2007 17:59:11 -0800 (PST) Received: by 10.90.50.16 with HTTP; Mon, 19 Feb 2007 17:59:11 -0800 (PST) Message-ID: <30b660a20702191759x505570f2jbf307e1581294a35@mail.gmail.com> Date: Mon, 19 Feb 2007 17:59:11 -0800 From: "Mark Davis" To: "Martin Hosken" Subject: Re: [Ltru] Re: Identifying script (or global) variants In-Reply-To: <45DA54A0.3080007@sil.org> MIME-Version: 1.0 References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> X-Google-Sender-Auth: 436f8a830166a416 X-Spam-Score: 0.5 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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="===============0997948833==" Errors-To: ltru-bounces@ietf.org --===============0997948833== Content-Type: multipart/alternative; boundary="----=_Part_15747_5859292.1171936751331" ------=_Part_15747_5859292.1171936751331 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline VGhhdCdzIGEgZ29vZCBxdWVzdGlvbi4gT25lIG9wdGlvbiwgbm90IHN1cmUgYWJvdXQgaXQgdGhv dWdodCwgaXMgdG8gaGF2ZQp0aGUgY2Fub25pY2FsIGZvcm0gcHV0IHZhcmlhbnRzIGluIGFscGhh YmV0aWNhbCBvcmRlci4gVGhhdCB3YXkgYXQgbGVhc3QgdGhlCnJlc3VsdCB3b3VsZCBiZSBwcmVk aWN0YWJsZS4KCk1hcmsKCk9uIDIvMTkvMDcsIE1hcnRpbiBIb3NrZW4gPG1hcnRpbl9ob3NrZW5A c2lsLm9yZz4gd3JvdGU6Cj4KPiBEZWFyIERvdWcsCj4KPiA+IEZvciByZWZlcmVuY2UsIGhlcmUn cyBhIGJyaWVmIHN1bW1hcnkgb2YgdGhlIGV4aXN0aW5nIHZhcmlhbnQgc3VidGFncwo+ID4gYW5k IHRoZSB0eXBlIG9mIHZhcmlhdGlvbiBpbmRpY2F0ZWQgYnkgZWFjaC4KPiA+Cj4gPiBEaWZmZXJl bmNlIGluIHdyaXRpbmcgc3lzdGVtIChtYWpvcik6Cj4gPiAgICBMYW5ndWFnZS1pbmRlcGVuZGVu dDogIGZvbmlwYSwgZm9udXBhCj4gPiAgICBMYW5ndWFnZS1kZXBlbmRlbnQ6ICBtb25vdG9uLCBw b2x5dG9uCj4gPgo+ID4gRGlmZmVyZW5jZSBpbiBvcnRob2dyYXBoeSAobWlub3IpOgo+ID4gICAg MTkwMSwgMTk5Ngo+ID4KPiA+IERpYWxlY3Q6Cj4gPiAgICBhcmV2ZWxhLCBhcmV2bWRhLiBib29u dCwgbmVkaXMsIHJvemFqLCBzY291c2UKPgo+IFRoYW5rcyBmb3IgdGhpcyBsaXN0LiBIbW0uIFll cyBJIHByb2JhYmx5IGRvIG5lZWQgdG8gaW5jbHVkZSB0aGUKPiBsYW5ndWFnZSBzcGVjaWZpYyBv cnRob2dyYXBoeS9zY3JpcHQgdmFyaWFudHMsIGJ1dCBub3QgdGhlIGRpYWxlY3Qgb25lcy4KPiA+ Cj4gPiBOb3RlIHRoYXQgIm1ham9yIiBhbmQgIm1pbm9yIiBhcmUgaW50ZW5kZWQgdG8gYmUgdmFn dWVseSBkZXNjcmlwdGl2ZSwKPiA+IG5vdCB2YWx1ZSBqdWRnbWVudHMuICAgSSBjb25zaWRlcmVk IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gIsOfIiBhbmQKPiA+ICJzcyIgdG8gYmUgbGVzcyBtYWpv ciB0aGFuIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdHJhZGl0aW9uYWwKPiA+IGFscGhhYmV0cyBh bmQgcHVycG9zZS1idWlsdCBwaG9uZXRpYyBhbHBoYWJldHMuICBJIHJlYWxseSwgcmVhbGx5Cj4g PiBkb24ndCB3YW50IHRvIHJlb3BlbiB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciBJUEEgaXMgYSBz Y3JpcHQhICBUaGVzZQo+ID4gY2F0ZWdvcmllcyBtYXkgYmUgbWVyZ2VkLCBvciBkaXZpZGVkIGFs b25nIGRpZmZlcmVudCBsaW5lcy4KPgo+IE5laXRoZXIgZG8gSSB3YW50IHRvIHJlb3BlbiB0aGF0 IGRlYmF0ZS4gQnV0IEkgZG8gaGF2ZSBzb21lIGJhc2ljCj4gcXVlc3Rpb25zIHRoYXQgSSBob3Bl IHlvdSBjYW4gaGVscCB3aXRoLiBMZXQncyB0YWtlIHRoZSBleGFtcGxlIG9mCj4gc2NvdXNlIEVu Z2xpc2ggaW4gSVBBLiBIb3cgd291bGQgSSB0YWcgdGhpcz8KPgo+IGVuLUxhdG4tc2NvdXNlLWZv bmlwYQo+IGVuLUxhdG4tZm9uaXBhLXNjb3VzZQo+IGVuLWZvbmlwYS1zY291c2UKPiBlbi1zY291 c2UtZm9uaXBhCj4KPiBOb3cgaWYgSSB3ZXJlIHRvIHdhbnQgdG8gZ2V0IGhvbGQgb2YgYW55IHNj b3VzZSB0ZXh0IGluIElQQSwgd2hhdCBzaG91bGQKPiBteSBSRkMgNDY0NyBmaWx0ZXIgYmU/Cj4K PiBlbi0qLWZvbmlwYS1zY291c2UKPiBlbi0qLXNjb3VzZS1mb25pcGEKPgo+IGRvIEkgcmVhbGx5 IG5lZWQgdG8gaGF2ZSB0d28gZmlsdGVycyBmb3IgdGhpcz8KPgo+ID4gTXkgb3BpbmlvbiBpcyB0 aGF0IHZhcmlhbnRzIGJ5IHRoZWlyIG5hdHVyZSBhcmUgYSBiaXQgb2YgYSBjYXRjaC1hbGwKPiA+ IGNhdGVnb3J5LCBhbmQgaXQgd2lsbCBhbHdheXMgYmUgbmVjZXNzYXJ5IHRvIHVwZGF0ZSBzb2Z0 d2FyZSB0byBzb21lCj4gPiBleHRlbnQgdG8gcmVmbGVjdCBjaGFuZ2VzIGluIHRoZSBSZWdpc3Ry eS4gIFlvdSB3aWxsIG5lZWQgdG8gZG8gdGhhdAo+ID4gYW55d2F5IGlmIHlvdSB3aXNoIHRvIG1h a2Ugc2VtYW50aWMgdXNlIG9mIHRoZSBzdWJ0YWdzIChmb3IgZXhhbXBsZSwKPiA+IHN3aXRjaGlu ZyB0byBhbiBJUEEtZW5hYmxlZCBmb250IHVwb24gc2VlaW5nIHRoZSAiZm9uaXBhIiBzdWJ0YWcp Lgo+Cj4gR2l2ZW4gdGhlIG51bWJlciBvZiBvcnRob2dyYXBoeSB2YXJpYW50cyBpbiBsYW5ndWFn ZXMgYXJvdW5kIHRoZSB3b3JsZCwKPiBJIHdvbmRlciB3aGF0IHRoZSBiZXN0IHdheSB0byBoYW5k bGUgdGhlbSBhbGwgaXMuIERvIHdlIChJJ20gdGhpbmtpbmcKPiBTSUwgd2l0aCBpdHMgaW52b2x2 ZW1lbnQgaW4gc28gbWFueSBsYW5ndWFnZXMgYW5kIGxpbmd1aXN0cyB3aXRoIHRoZWlyCj4gdGVz dCBvcnRob2dyYXBoaWVzLCBldGMuKSBuZWVkIHRvIHN1Ym1pdCBldmVyeSBzaW5nbGUgb25lLCBv ciB3b3VsZCBpdAo+IGhlbHAgeW91IGd1eXMgaWYgd2Ugd2VyZSB0byBpbnRlcm5hbGx5IHJlZ2lz dGVyIHRoZW0gKHBlcmhhcHMgdXNpbmcgYQo+IHNpbmdsZXRvbiBiYXNlZCBleHRlbnNpb24pIGFu ZCB0aGVuIGZvcndhcmQgdGhlIGludGVyZXN0aW5nIG9uZXMgdG8geW91Pwo+Cj4gWW91cnMsCj4g TWFydGluCj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCj4gTHRydSBtYWlsaW5nIGxpc3QKPiBMdHJ1QGlldGYub3JnCj4gaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo+CgoKCi0tIApNYXJrCg== ------=_Part_15747_5859292.1171936751331 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhhdCYjMzk7cyBhIGdvb2QgcXVlc3Rpb24uIE9uZSBvcHRpb24sIG5vdCBzdXJlIGFib3V0IGl0 IHRob3VnaHQsIGlzIHRvIGhhdmUgdGhlIGNhbm9uaWNhbCBmb3JtIHB1dCB2YXJpYW50cyBpbiBh bHBoYWJldGljYWwgb3JkZXIuIFRoYXQgd2F5IGF0IGxlYXN0IHRoZSByZXN1bHQgd291bGQgYmUg cHJlZGljdGFibGUuPGJyPjxicj5NYXJrPGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9x dW90ZSI+Ck9uIDIvMTkvMDcsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5NYXJ0aW4gSG9z a2VuPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbl9ob3NrZW5Ac2lsLm9yZyI+bWFydGlu X2hvc2tlbkBzaWwub3JnPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAy MDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgpEZWFy IERvdWcsPGJyPjxicj4mZ3Q7IEZvciByZWZlcmVuY2UsIGhlcmUmIzM5O3MgYSBicmllZiBzdW1t YXJ5IG9mIHRoZSBleGlzdGluZyB2YXJpYW50IHN1YnRhZ3M8YnI+Jmd0OyBhbmQgdGhlIHR5cGUg b2YgdmFyaWF0aW9uIGluZGljYXRlZCBieSBlYWNoLjxicj4mZ3Q7PGJyPiZndDsgRGlmZmVyZW5j ZSBpbiB3cml0aW5nIHN5c3RlbSAobWFqb3IpOjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7TGFuZ3VhZ2UtaW5kZXBlbmRlbnQ6Jm5ic3A7Jm5ic3A7Zm9uaXBhLCBmb251cGEKPGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtMYW5ndWFnZS1kZXBlbmRlbnQ6Jm5ic3A7Jm5ic3A7 bW9ub3RvbiwgcG9seXRvbjxicj4mZ3Q7PGJyPiZndDsgRGlmZmVyZW5jZSBpbiBvcnRob2dyYXBo eSAobWlub3IpOjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7MTkwMSwgMTk5Njxicj4m Z3Q7PGJyPiZndDsgRGlhbGVjdDo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FyZXZl bGEsIGFyZXZtZGEuIGJvb250LCBuZWRpcywgcm96YWosIHNjb3VzZTxicj48YnI+VGhhbmtzIGZv ciB0aGlzIGxpc3QuIEhtbS4gWWVzIEkgcHJvYmFibHkgZG8gbmVlZCB0byBpbmNsdWRlIHRoZQo8 YnI+bGFuZ3VhZ2Ugc3BlY2lmaWMgb3J0aG9ncmFwaHkvc2NyaXB0IHZhcmlhbnRzLCBidXQgbm90 IHRoZSBkaWFsZWN0IG9uZXMuPGJyPiZndDs8YnI+Jmd0OyBOb3RlIHRoYXQgJnF1b3Q7bWFqb3Im cXVvdDsgYW5kICZxdW90O21pbm9yJnF1b3Q7IGFyZSBpbnRlbmRlZCB0byBiZSB2YWd1ZWx5IGRl c2NyaXB0aXZlLDxicj4mZ3Q7IG5vdCB2YWx1ZSBqdWRnbWVudHMuJm5ic3A7Jm5ic3A7IEkgY29u c2lkZXJlZCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuICZxdW90O8OfJnF1b3Q7IGFuZAo8YnI+Jmd0 OyAmcXVvdDtzcyZxdW90OyB0byBiZSBsZXNzIG1ham9yIHRoYW4gdGhlIGRpZmZlcmVuY2UgYmV0 d2VlbiB0cmFkaXRpb25hbDxicj4mZ3Q7IGFscGhhYmV0cyBhbmQgcHVycG9zZS1idWlsdCBwaG9u ZXRpYyBhbHBoYWJldHMuJm5ic3A7Jm5ic3A7SSByZWFsbHksIHJlYWxseTxicj4mZ3Q7IGRvbiYj Mzk7dCB3YW50IHRvIHJlb3BlbiB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciBJUEEgaXMgYSBzY3Jp cHQhJm5ic3A7Jm5ic3A7VGhlc2UKPGJyPiZndDsgY2F0ZWdvcmllcyBtYXkgYmUgbWVyZ2VkLCBv ciBkaXZpZGVkIGFsb25nIGRpZmZlcmVudCBsaW5lcy48YnI+PGJyPk5laXRoZXIgZG8gSSB3YW50 IHRvIHJlb3BlbiB0aGF0IGRlYmF0ZS4gQnV0IEkgZG8gaGF2ZSBzb21lIGJhc2ljPGJyPnF1ZXN0 aW9ucyB0aGF0IEkgaG9wZSB5b3UgY2FuIGhlbHAgd2l0aC4gTGV0JiMzOTtzIHRha2UgdGhlIGV4 YW1wbGUgb2Y8YnI+c2NvdXNlIEVuZ2xpc2ggaW4gSVBBLiBIb3cgd291bGQgSSB0YWcgdGhpcz8K PGJyPjxicj5lbi1MYXRuLXNjb3VzZS1mb25pcGE8YnI+ZW4tTGF0bi1mb25pcGEtc2NvdXNlPGJy PmVuLWZvbmlwYS1zY291c2U8YnI+ZW4tc2NvdXNlLWZvbmlwYTxicj48YnI+Tm93IGlmIEkgd2Vy ZSB0byB3YW50IHRvIGdldCBob2xkIG9mIGFueSBzY291c2UgdGV4dCBpbiBJUEEsIHdoYXQgc2hv dWxkPGJyPm15IFJGQyA0NjQ3IGZpbHRlciBiZT88YnI+PGJyPmVuLSotZm9uaXBhLXNjb3VzZQo8 YnI+ZW4tKi1zY291c2UtZm9uaXBhPGJyPjxicj5kbyBJIHJlYWxseSBuZWVkIHRvIGhhdmUgdHdv IGZpbHRlcnMgZm9yIHRoaXM/PGJyPjxicj4mZ3Q7IE15IG9waW5pb24gaXMgdGhhdCB2YXJpYW50 cyBieSB0aGVpciBuYXR1cmUgYXJlIGEgYml0IG9mIGEgY2F0Y2gtYWxsPGJyPiZndDsgY2F0ZWdv cnksIGFuZCBpdCB3aWxsIGFsd2F5cyBiZSBuZWNlc3NhcnkgdG8gdXBkYXRlIHNvZnR3YXJlIHRv IHNvbWUKPGJyPiZndDsgZXh0ZW50IHRvIHJlZmxlY3QgY2hhbmdlcyBpbiB0aGUgUmVnaXN0cnku Jm5ic3A7Jm5ic3A7WW91IHdpbGwgbmVlZCB0byBkbyB0aGF0PGJyPiZndDsgYW55d2F5IGlmIHlv dSB3aXNoIHRvIG1ha2Ugc2VtYW50aWMgdXNlIG9mIHRoZSBzdWJ0YWdzIChmb3IgZXhhbXBsZSw8 YnI+Jmd0OyBzd2l0Y2hpbmcgdG8gYW4gSVBBLWVuYWJsZWQgZm9udCB1cG9uIHNlZWluZyB0aGUg JnF1b3Q7Zm9uaXBhJnF1b3Q7IHN1YnRhZykuCjxicj48YnI+R2l2ZW4gdGhlIG51bWJlciBvZiBv cnRob2dyYXBoeSB2YXJpYW50cyBpbiBsYW5ndWFnZXMgYXJvdW5kIHRoZSB3b3JsZCw8YnI+SSB3 b25kZXIgd2hhdCB0aGUgYmVzdCB3YXkgdG8gaGFuZGxlIHRoZW0gYWxsIGlzLiBEbyB3ZSAoSSYj Mzk7bSB0aGlua2luZzxicj5TSUwgd2l0aCBpdHMgaW52b2x2ZW1lbnQgaW4gc28gbWFueSBsYW5n dWFnZXMgYW5kIGxpbmd1aXN0cyB3aXRoIHRoZWlyCjxicj50ZXN0IG9ydGhvZ3JhcGhpZXMsIGV0 Yy4pIG5lZWQgdG8gc3VibWl0IGV2ZXJ5IHNpbmdsZSBvbmUsIG9yIHdvdWxkIGl0PGJyPmhlbHAg eW91IGd1eXMgaWYgd2Ugd2VyZSB0byBpbnRlcm5hbGx5IHJlZ2lzdGVyIHRoZW0gKHBlcmhhcHMg dXNpbmcgYTxicj5zaW5nbGV0b24gYmFzZWQgZXh0ZW5zaW9uKSBhbmQgdGhlbiBmb3J3YXJkIHRo ZSBpbnRlcmVzdGluZyBvbmVzIHRvIHlvdT8KPGJyPjxicj5Zb3Vycyw8YnI+TWFydGluPGJyPjxi cj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ THRydSBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOkx0cnVAaWV0Zi5vcmciPkx0cnVA aWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2x0cnUiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUK PC9hPjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJy Pk1hcmsK ------=_Part_15747_5859292.1171936751331-- --===============0997948833== 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 --===============0997948833==-- From ltru-bounces@ietf.org Mon Feb 19 22:22:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLZr-0001CA-QP; Mon, 19 Feb 2007 22:22:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLZq-0001Bg-0S for ltru@lists.ietf.org; Mon, 19 Feb 2007 22:22:02 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJLZm-0000Fj-Sn for ltru@lists.ietf.org; Mon, 19 Feb 2007 22:22:01 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l1K3Li2j010247 for ; Tue, 20 Feb 2007 12:21:45 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 024a_7daadece_c091_11db_8a6d_0014221f2a2d; Tue, 20 Feb 2007 12:21:44 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:58904) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 20 Feb 2007 12:20:48 +0900 Message-Id: <6.0.0.20.2.20070220113003.04e32730@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 20 Feb 2007 11:38:33 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Erratum ? (upper-case X in numeric character references) In-Reply-To: <45DA1EBB.3DD9@xyzzy.claranet.de> References: <45DA1EBB.3DD9@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org What Frank is saying is that our current ABNF allows an upper-case 'X' in numeric character references, but that this isn't allowed in XML. My understanding is that this is only relevant for the registry itself, that there are extremely few cases of numeric character references currently (I counted 14, all of them with a lower-case x). I don't think we need a formal erratum, because we have other means to make sure no upper-case X gets into the registry. But I definitely support fixing this in RFC 4646bis. Others, please express your preferences. At 07:03 07/02/20, Frank Ellermann wrote: >Hi, thinking about John's I-D.klensin-unicode-escapes-02 my idea was >to simply copy from RFC 4646: > > UNICHAR = "&#x" 2*6HEXDIG ";" > >BUT, it's wrong, isn't it ? I've now proposed this beast: > > UNICHAR = %x26.23.78 2*6HEXDIG ";" Just a detail: What about UNICHAR = "&#" %x78 2*6HEXDIG ";" Maybe just a tiny bit more readable, but I don't care too much. Regards, Martin. >IOW ģ is fine, but ģ (X instead of x) is not, or is it ? >See http://www.w3.org/TR/REC-xml/#sec-references > >Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Feb 19 22:22:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLZt-0001CM-TL; Mon, 19 Feb 2007 22:22:05 -0500 From ltru-bounces@ietf.org Mon Feb 19 22:22:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLZr-0001CA-QP; Mon, 19 Feb 2007 22:22:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLZq-0001Bg-0S for ltru@lists.ietf.org; Mon, 19 Feb 2007 22:22:02 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJLZm-0000Fj-Sn for ltru@lists.ietf.org; Mon, 19 Feb 2007 22:22:01 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l1K3Li2j010247 for ; Tue, 20 Feb 2007 12:21:45 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 024a_7daadece_c091_11db_8a6d_0014221f2a2d; Tue, 20 Feb 2007 12:21:44 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:58904) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 20 Feb 2007 12:20:48 +0900 Message-Id: <6.0.0.20.2.20070220113003.04e32730@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 20 Feb 2007 11:38:33 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Erratum ? (upper-case X in numeric character references) In-Reply-To: <45DA1EBB.3DD9@xyzzy.claranet.de> References: <45DA1EBB.3DD9@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org What Frank is saying is that our current ABNF allows an upper-case 'X' in numeric character references, but that this isn't allowed in XML. My understanding is that this is only relevant for the registry itself, that there are extremely few cases of numeric character references currently (I counted 14, all of them with a lower-case x). I don't think we need a formal erratum, because we have other means to make sure no upper-case X gets into the registry. But I definitely support fixing this in RFC 4646bis. Others, please express your preferences. At 07:03 07/02/20, Frank Ellermann wrote: >Hi, thinking about John's I-D.klensin-unicode-escapes-02 my idea was >to simply copy from RFC 4646: > > UNICHAR = "&#x" 2*6HEXDIG ";" > >BUT, it's wrong, isn't it ? I've now proposed this beast: > > UNICHAR = %x26.23.78 2*6HEXDIG ";" Just a detail: What about UNICHAR = "&#" %x78 2*6HEXDIG ";" Maybe just a tiny bit more readable, but I don't care too much. Regards, Martin. >IOW ģ is fine, but ģ (X instead of x) is not, or is it ? >See http://www.w3.org/TR/REC-xml/#sec-references > >Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Feb 19 22:22:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLZt-0001CM-TL; Mon, 19 Feb 2007 22:22:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLZs-0001CE-9R for ltru@ietf.org; Mon, 19 Feb 2007 22:22:04 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJLZp-0000G0-KU for ltru@ietf.org; Mon, 19 Feb 2007 22:22:04 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l1K3Lmgf001729 for ; Tue, 20 Feb 2007 12:21:48 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 64f4_7fa337b2_c091_11db_80ae_0014221fa3c9; Tue, 20 Feb 2007 12:21:47 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:58904) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 20 Feb 2007 12:20:51 +0900 Message-Id: <6.0.0.20.2.20070220120742.07672b80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 20 Feb 2007 12:13:52 +0900 To: Martin Hosken , Doug Ewell From: Martin Duerst Subject: Re: [Ltru] Re: Identifying script (or global) variants In-Reply-To: <45DA54A0.3080007@sil.org> References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 10:53 07/02/20, Martin Hosken wrote: >Neither do I want to reopen that debate. But I do have some basic >questions that I hope you can help with. Let's take the example of >scouse English in IPA. How would I tag this? > >en-Latn-scouse-fonipa >en-Latn-fonipa-scouse >en-fonipa-scouse >en-scouse-fonipa > >Now if I were to want to get hold of any scouse text in IPA, what should >my RFC 4647 filter be? > >en-*-fonipa-scouse >en-*-scouse-fonipa > >do I really need to have two filters for this? As Mark said, an interesting question, and one that we haven't yet addressed, probably mostly just because we didn't have that many variants yet. Using alphabetical order would be one solution, but the results may look a bit too unnatural. Using 'major before minor' would work in general, but in many cases, there will be different opinions. Should we change RFC 4647 to say that the order of variants doesn't count? Are there other aspects of our syntax where the same problem arises? It seems to happen at least for extensions. >> My opinion is that variants by their nature are a bit of a catch-all >> category, and it will always be necessary to update software to some >> extent to reflect changes in the Registry. You will need to do that >> anyway if you wish to make semantic use of the subtags (for example, >> switching to an IPA-enabled font upon seeing the "fonipa" subtag). > >Given the number of orthography variants in languages around the world, >I wonder what the best way to handle them all is. Do we (I'm thinking >SIL with its involvement in so many languages and linguists with their >test orthographies, etc.) need to submit every single one, or would it >help you guys if we were to internally register them (perhaps using a >singleton based extension) and then forward the interesting ones to you? If you want to use a singleton extension, then you have to apply for it, andReceived: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLZs-0001CE-9R for ltru@ietf.org; Mon, 19 Feb 2007 22:22:04 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJLZp-0000G0-KU for ltru@ietf.org; Mon, 19 Feb 2007 22:22:04 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l1K3Lmgf001729 for ; Tue, 20 Feb 2007 12:21:48 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 64f4_7fa337b2_c091_11db_80ae_0014221fa3c9; Tue, 20 Feb 2007 12:21:47 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:58904) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 20 Feb 2007 12:20:51 +0900 Message-Id: <6.0.0.20.2.20070220120742.07672b80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 20 Feb 2007 12:13:52 +0900 To: Martin Hosken , Doug Ewell From: Martin Duerst Subject: Re: [Ltru] Re: Identifying script (or global) variants In-Reply-To: <45DA54A0.3080007@sil.org> References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 10:53 07/02/20, Martin Hosken wrote: >Neither do I want to reopen that debate. But I do have some basic >questions that I hope you can help with. Let's take the example of >scouse English in IPA. How would I tag this? > >en-Latn-scouse-fonipa >en-Latn-fonipa-scouse >en-fonipa-scouse >en-scouse-fonipa > >Now if I were to want to get hold of any scouse text in IPA, what should >my RFC 4647 filter be? > >en-*-fonipa-scouse >en-*-scouse-fonipa > >do I really need to have two filters for this? As Mark said, an interesting question, and one that we haven't yet addressed, probably mostly just because we didn't have that many variants yet. Using alphabetical order would be one solution, but the results may look a bit too unnatural. Using 'major before minor' would work in general, but in many cases, there will be different opinions. Should we change RFC 4647 to say that the order of variants doesn't count? Are there other aspects of our syntax where the same problem arises? It seems to happen at least for extensions. >> My opinion is that variants by their nature are a bit of a catch-all >> category, and it will always be necessary to update software to some >> extent to reflect changes in the Registry. You will need to do that >> anyway if you wish to make semantic use of the subtags (for example, >> switching to an IPA-enabled font upon seeing the "fonipa" subtag). > >Given the number of orthography variants in languages around the world, >I wonder what the best way to handle them all is. Do we (I'm thinking >SIL with its involvement in so many languages and linguists with their >test orthographies, etc.) need to submit every single one, or would it >help you guys if we were to internally register them (perhaps using a >singleton based extension) and then forward the interesting ones to you? If you want to use a singleton extension, then you have to apply for it, and once you applied, you would keep you own registry. There would not be a need to forward interesting ones to the general registry, as everybody can take the variants from your registry if they need them. The problem might be that the singleton extensions were imagined for 'by-topic' extensions, and your registry could end up with all kinds of extensions. 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 once you applied, you would keep you own registry. There would not be a need to forward interesting ones to the general registry, as everybody can take the variants from your registry if they need them. The problem might be that the singleton extensions were imagined for 'by-topic' extensions, and your registry could end up with all kinds of extensions. 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 Mon Feb 19 22:25:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLcn-0004Fw-AP; Mon, 19 Feb 2007 22:25:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLcm-0004ED-Es for ltru@lists.ietf.org; Mon, 19 Feb 2007 22:25:04 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJLcj-0001Xx-7C for ltru@lists.ietf.org; Mon, 19 Feb 2007 22:25:04 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HJLcf-0006yb-9r; Mon, 19 Feb 2007 22:24:57 -0500 Date: Mon, 19 Feb 2007 22:24:57 -0500 To: Martin Duerst Subject: Re: [Ltru] Erratum ? (upper-case X in numeric character references) Message-ID: <20070220032457.GB19815@mercury.ccil.org> References: <45DA1EBB.3DD9@xyzzy.claranet.de> <6.0.0.20.2.20070220113003.04e32730@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20070220113003.04e32730@localhost> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > But I definitely support fixing this in RFC 4646bis. Others, > please express your preferences. +1 -- I am expressing my opinion. When my John Cowan honorable and gallant friend is called, cowan@ccil.org he will express his opinion. This is http://www.ccil.org/~cowan the process which we call Debate. --Winston Churchill _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Feb 19 23:16:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJMQT-0006d4-G4; Mon, 19 Feb 2007 23:16:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJMQS-0006cz-Ex for ltru@lists.ietf.org; Mon, 19 Feb 2007 23:16:24 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJMQQ-0007ck-16 for ltru@lists.ietf.org; Mon, 19 Feb 2007 23:16:24 -0500 Received: from [10.72.72.51] (snvvpn1-10-72-72-c51.corp.yahoo.com [10.72.72.51]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l1K4G82o082077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Feb 2007 20:16:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=BH3mtjWpLQC+EgdUq+kYcg3CCFM/UDGFYHCqi+3WX1XPwc+Gp2lKh6Vewr7QAYg5 Message-ID: <45DA7606.8010103@yahoo-inc.com> Date: Mon, 19 Feb 2007 20:16:06 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Erratum ? (upper-case X in numeric character references) References: <45DA1EBB.3DD9@xyzzy.claranet.de> <6.0.0.20.2.20070220113003.04e32730@localhost> In-Reply-To: <6.0.0.20.2.20070220113003.04e32730@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Could we please just bag entities and use UTF-8 in the registry? The entities are ugly, unreadable, and unnecessary in this modern era of Unicode. Some folks on the ietf-languages list have even had trouble submitting them (using a Web mail system appears to cause interference between the entities and the mail system's Web pages). Addison Martin Duerst wrote: > What Frank is saying is that our current ABNF allows an upper-case > 'X' in numeric character references, but that this isn't allowed > in XML. > > My understanding is that this is only relevant for the registry > itself, that there are extremely few cases of numeric character > references currently (I counted 14, all of them with a lower-case x). > > I don't think we need a formal erratum, because we have other > means to make sure no upper-case X gets into the registry. > > But I definitely support fixing this in RFC 4646bis. Others, > please express your preferences. > > At 07:03 07/02/20, Frank Ellermann wrote: >> Hi, thinking about John's I-D.klensin-unicode-escapes-02 my idea was >> to simply copy from RFC 4646: >> >> UNICHAR = "&#x" 2*6HEXDIG ";" >> >> BUT, it's wrong, isn't it ? I've now proposed this beast: >> >> UNICHAR = %x26.23.78 2*6HEXDIG ";" > > Just a detail: What about > > UNICHAR = "&#" %x78 2*6HEXDIG ";" > > Maybe just a tiny bit more readable, but I don't care too much. > > Regards, Martin. > >> IOW ģ is fine, but ģ (X instead of x) is not, or is it ? >> See http://www.w3.org/TR/REC-xml/#sec-references >> >> Frank >> >> >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 00:06:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJNCs-0005aA-0E; Tue, 20 Feb 2007 00:06:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJNCr-0005a2-6v for ltru@lists.ietf.org; Tue, 20 Feb 2007 00:06:25 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJNCn-0003S6-3g for ltru@lists.ietf.org; Tue, 20 Feb 2007 00:06:25 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l1K566ip026064 for ; Tue, 20 Feb 2007 14:06:06 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 65c3_1211b8d6_c0a0_11db_975d_0014221fa3c9; Tue, 20 Feb 2007 14:06:06 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:52922) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 20 Feb 2007 14:05:10 +0900 Message-Id: <6.0.0.20.2.20070220132534.04e89910@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 20 Feb 2007 13:26:04 +0900 To: Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Erratum ? (upper-case X in numeric character references) In-Reply-To: <45DA7606.8010103@yahoo-inc.com> References: <45DA1EBB.3DD9@xyzzy.claranet.de> <6.0.0.20.2.20070220113003.04e32730@localhost> <45DA7606.8010103@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 13:16 07/02/20, Addison Phillips wrote: >Could we please just bag entities and use UTF-8 in the registry? The entities are ugly, unreadable, and unnecessary in this modern era of Unicode. Some folks on the ietf-languages list have even had trouble submitting them (using a Web mail system appears to cause interference between the entities and the mail system's Web pages). I would be happy to support this, too. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 00:25:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJNVa-0007Lv-Me; Tue, 20 Feb 2007 00:25:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJNVZ-0007Lq-KP for ltru@lists.ietf.org; Tue, 20 Feb 2007 00:25:45 -0500 Received: from smtp5.pp.htv.fi ([213.243.153.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJNVY-0007WJ-8n for ltru@lists.ietf.org; Tue, 20 Feb 2007 00:25:45 -0500 Received: from Raahattava (cs181252091.pp.htv.fi [82.181.252.91]) by smtp5.pp.htv.fi (Postfix) with ESMTP id 6A6765BC0E6; Tue, 20 Feb 2007 07:25:29 +0200 (EET) From: "Erkki I. Kolehmainen" To: "'Martin Duerst'" , "'Addison Phillips'" Subject: Re: [Ltru] Erratum ? (upper-case X in numeric character references) Date: Tue, 20 Feb 2007 07:25:27 +0200 Message-ID: <000101c754af$8799ebd0$0c00a8c0@Raahattava> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <6.0.0.20.2.20070220132534.04e89910@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'Frank Ellermann' , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Erkki I. Kolehmainen Tilkankatu 12 A 3, FI-00300 Helsinki, Finland Puh. (09) 4368 2643, 0400 825 943; Tel. +358 9 4368 2643, +358 400 825 = 943 =20 -----Alkuperainen viesti----- Lahettaja: Martin Duerst [mailto:duerst@it.aoyama.ac.jp]=20 Lahetetty: 20. helmikuuta 2007 6:26 Vastaanottaja: Addison Phillips Kopio: Frank Ellermann; ltru@lists.ietf.org Aihe: Re: [Ltru] Erratum ? (upper-case X in numeric character = references) At 13:16 07/02/20, Addison Phillips wrote: >Could we please just bag entities and use UTF-8 in the registry? The=20 >entities are ugly, unreadable, and unnecessary in this modern era of=20 >Unicode. Some folks on the ietf-languages list have even had trouble=20 >submitting them (using a Web mail system appears to cause interference=20 >between the entities and the mail system's Web pages). I would be happy to support this, too. 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 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 01:33:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJOYW-0004fQ-Qo; Tue, 20 Feb 2007 01:32:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJOYV-0004e6-U1 for ltru@ietf.org; Tue, 20 Feb 2007 01:32:51 -0500 Received: from smtp1.wsfo.org ([208.145.81.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJOYP-0003oQ-MC for ltru@ietf.org; Tue, 20 Feb 2007 01:32:51 -0500 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp1.wsfo.org (8.13.1/8.13.1) with ESMTP id l1K6WjCx004493 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 20 Feb 2007 01:32:45 -0500 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.51 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.150.104.82] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 137084838 for ltru@ietf.org; Tue, 20 Feb 2007 01:32:44 -0500 Message-ID: <45DA9608.5080404@sil.org> Date: Tue, 20 Feb 2007 13:32:40 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: LTRU Working Group Subject: Re: [Ltru] Re: Identifying script (or global) variants References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> <6.0.0.20.2.20070220120742.07672b80@localhost> In-Reply-To: <6.0.0.20.2.20070220120742.07672b80@localhost> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear Martin, > As Mark said, an interesting question, and one that we haven't > yet addressed, probably mostly just because we didn't have that > many variants yet. > > Using alphabetical order would be one solution, but the results > may look a bit too unnatural. Using 'major before minor' would > work in general, but in many cases, there will be different opinions. > Thinking a little more about it. I think part of the issue arises from the different domains that variants can fall into. In the scouse in IPA example, we are dealing with two variants from two different domains: dialect and script. I don't think it matters what the relative order of the domains is and there is no way to do major vs minor between domains. So sorting alphabetically is as good as any. This should probably apply to extensions too. Even if you went for a domain based approach where do you draw the line: de-1901-fonipa Language tags describe 3 things: language, script and region. Therefore variants can modify one or more of those parameters. Given that regional variants are handled via other regions (AFAIK). That leaves us with language, script, language+script (=orthography). But I'm not sure if that helps us any. Yours, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 01:34:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJOaO-0005vO-RD; Tue, 20 Feb 2007 01:34:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJOaN-0005v1-Tn for ltru@ietf.org; Tue, 20 Feb 2007 01:34:47 -0500 Received: from smtp1.wsfo.org ([208.145.81.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJOaM-0004E8-LT for ltru@ietf.org; Tue, 20 Feb 2007 01:34:47 -0500 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp1.wsfo.org (8.13.1/8.13.1) with ESMTP id l1K6YfG2004526 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 20 Feb 2007 01:34:46 -0500 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.51 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.150.104.82] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 137084917 for ltru@ietf.org; Tue, 20 Feb 2007 01:34:45 -0500 Message-ID: <45DA9682.6000500@sil.org> Date: Tue, 20 Feb 2007 13:34:42 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: LTRU Working Group Subject: Re: [Ltru] Re: Identifying script (or global) variants References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> <30b660a20702191759x505570f2jbf307e1581294a35@mail.gmail.com> In-Reply-To: <30b660a20702191759x505570f2jbf307e1581294a35@mail.gmail.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear All, I realise I may have slipped in 2 questions here that I was after asking. In addition to knowing which order variants can occur, I'm also not sure whether Latn is required since en has a Latn suppress script on it. Does adding fonipa require that the Latn reappear or can it remain suppressed? > > Neither do I want to reopen that debate. But I do have some basic > questions that I hope you can help with. Let's take the example of > scouse English in IPA. How would I tag this? > > en-Latn-scouse-fonipa > en-Latn-fonipa-scouse > en-fonipa-scouse > en-scouse-fonipa > TIA, Martin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 01:42:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJOhx-0000bj-C3; Tue, 20 Feb 2007 01:42:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJOhw-0000bb-43 for ltru@lists.ietf.org; Tue, 20 Feb 2007 01:42:36 -0500 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJOhr-0005Mr-Oi for ltru@lists.ietf.org; Tue, 20 Feb 2007 01:42:36 -0500 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 19 Feb 2007 22:42:31 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Mon, 19 Feb 2007 22:42:30 -0800 From: Peter Constable To: "Erkki I. Kolehmainen" , 'Martin Duerst' , 'Addison Phillips' Date: Mon, 19 Feb 2007 22:42:25 -0800 Subject: RE: [Ltru] Erratum ? (upper-case X in numeric character references) Thread-Topic: [Ltru] Erratum ? (upper-case X in numeric character references) Thread-Index: AcdUr50KVD8N2tu0QpS3LHGnaNAORAACqR7w Message-ID: References: <6.0.0.20.2.20070220132534.04e89910@localhost> <000101c754af$8799ebd0$0c00a8c0@Raahattava> In-Reply-To: <000101c754af$8799ebd0$0c00a8c0@Raahattava> 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 Cc: 'Frank Ellermann' , "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Peter Constable -----Original Message----- From: Erkki I. Kolehmainen [mailto:eik@iki.fi] Sent: Monday, February 19, 2007 9:25 PM To: 'Martin Duerst'; 'Addison Phillips' Cc: 'Frank Ellermann'; ltru@lists.ietf.org Subject: Re: [Ltru] Erratum ? (upper-case X in numeric character references= ) +1 Erkki I. Kolehmainen Tilkankatu 12 A 3, FI-00300 Helsinki, Finland Puh. (09) 4368 2643, 0400 825 943; Tel. +358 9 4368 2643, +358 400 825 943 -----Alkuperainen viesti----- Lahettaja: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] Lahetetty: 20. helmikuuta 2007 6:26 Vastaanottaja: Addison Phillips Kopio: Frank Ellermann; ltru@lists.ietf.org Aihe: Re: [Ltru] Erratum ? (upper-case X in numeric character references) At 13:16 07/02/20, Addison Phillips wrote: >Could we please just bag entities and use UTF-8 in the registry? The >entities are ugly, unreadable, and unnecessary in this modern era of >Unicode. Some folks on the ietf-languages list have even had trouble >submitting them (using a Web mail system appears to cause interference >between the entities and the mail system's Web pages). I would be happy to support this, too. 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 _______________________________________________ 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 Tue Feb 20 01:52:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJOru-000518-BJ; Tue, 20 Feb 2007 01:52:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJOrt-00050y-Uj for ltru@ietf.org; Tue, 20 Feb 2007 01:52:53 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJOrs-0006Xp-4z for ltru@ietf.org; Tue, 20 Feb 2007 01:52:53 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l1K6qoIS000688 for ; Tue, 20 Feb 2007 15:52:50 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 65c4_fb1c9e02_c0ae_11db_83dc_0014221fa3c9; Tue, 20 Feb 2007 15:52:50 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40544) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 20 Feb 2007 15:51:54 +0900 Message-Id: <6.0.0.20.2.20070220155007.04e771c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 20 Feb 2007 15:52:31 +0900 To: Martin Hosken , LTRU Working Group From: Martin Duerst Subject: Re: [Ltru] Re: Identifying script (or global) variants In-Reply-To: <45DA9682.6000500@sil.org> References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> <30b660a20702191759x505570f2jbf307e1581294a35@mail.gmail.com> <45DA9682.6000500@sil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 15:34 07/02/20, Martin Hosken wrote: >Dear All, > >I realise I may have slipped in 2 questions here that I was after >asking. In addition to knowing which order variants can occur, I'm also >not sure whether Latn is required since en has a Latn suppress script on >it. Does adding fonipa require that the Latn reappear or can it remain >suppressed? Thinking purely semantically, I think Latn can be even more supressed once fonipa is added :-). In other words, Latn might be suppressed, even on lanugages that otherwise don't suppress it, when fonipa is added. As an example, sr (assuming it means Serbian) would definitely need sr-Latn to say it's written in Latin, but sr-fonipa would be as good as sr-Latn-fonipa because fonipa implies Latn. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 01:54:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJOsz-0005Ag-W1; Tue, 20 Feb 2007 01:54:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJOsz-0005Ab-94 for ltru@ietf.org; Tue, 20 Feb 2007 01:54:01 -0500 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJOsx-0006jc-VO for ltru@ietf.org; Tue, 20 Feb 2007 01:54:01 -0500 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 19 Feb 2007 22:53:59 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Mon, 19 Feb 2007 22:53:59 -0800 From: Peter Constable To: LTRU Working Group Date: Mon, 19 Feb 2007 22:53:53 -0800 Subject: RE: [Ltru] Re: Identifying script (or global) variants Thread-Topic: [Ltru] Re: Identifying script (or global) variants Thread-Index: AcdUuToOPkxgKu+hSa+Qw8ananLg1gAAU3WQ Message-ID: References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> <30b660a20702191759x505570f2jbf307e1581294a35@mail.gmail.com> <45DA9682.6000500@sil.org> In-Reply-To: <45DA9682.6000500@sil.org> 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: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 way things are now, strictly speaking, both cho-fonipa and cho-Latn-fon= ipa (intentionally picking a non en example for a moment) are equally valid= . I was a little surprised -- I guess I was thinking fonipa would have spec= ified a prefix of Latn. Mind you, if Latn was specified as a prefix for fon= ipa, then there'd be a bit of confusion in the case of some languages, like= en, since they specify "Suppress-script: Latn". So, at present, it seems l= ike the recommendation implied by the current sub-tag registry and RFC 4646= (for good or bad) is *not* to include Latn. Peter Constable -----Original Message----- From: Martin Hosken [mailto:martin_hosken@sil.org] Sent: Monday, February 19, 2007 10:35 PM To: LTRU Working Group Subject: Re: [Ltru] Re: Identifying script (or global) variants Dear All, I realise I may have slipped in 2 questions here that I was after asking. In addition to knowing which order variants can occur, I'm also not sure whether Latn is required since en has a Latn suppress script on it. Does adding fonipa require that the Latn reappear or can it remain suppressed? > > Neither do I want to reopen that debate. But I do have some basic > questions that I hope you can help with. Let's take the example of > scouse English in IPA. How would I tag this? > > en-Latn-scouse-fonipa > en-Latn-fonipa-scouse > en-fonipa-scouse > en-scouse-fonipa > TIA, Martin _______________________________________________ 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 Tue Feb 20 02:02:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJP0s-0001xI-7O; Tue, 20 Feb 2007 02:02:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJP0q-0001t9-KR for ltru@ietf.org; Tue, 20 Feb 2007 02:02:08 -0500 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJP0o-0007ey-9C for ltru@ietf.org; Tue, 20 Feb 2007 02:02:08 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070220070205.CAXQ14346.mta13.adelphia.net@DGBP7M81>; Tue, 20 Feb 2007 02:02:05 -0500 Message-ID: <00fb01c754bd$085f6490$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> <6.0.0.20.2.20070220120742.07672b80@localhost> Subject: Re: [Ltru] Re: Identifying script (or global) variants Date: Mon, 19 Feb 2007 23:02:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > Using alphabetical order would be one solution, but the results may > look a bit too unnatural. Using 'major before minor' would work in > general, but in many cases, there will be different opinions. People will differ on which variants are more "major" than others. That's a certainty. I don't think it's reasonable to talk about "canonicalizing" tags by putting the variants in alphabetical order. That would put "boont" before "fonipa", bot "fonipa" before "scouse", which is completely arbitrary. It could also separate prefixes that include other variants. Let's say you have a variant "socal" that identifies the Southern California dialect of English (like, y'know, fer sure dude) and suppose you have another variant "orange" that identifies the Orange County variant of "en-socal" and has "en-socal" as its only Prefix. (I don't know of any uniquely Orange County dialect, but play along.) "Canonicalizing" the variants in alphabetical order would give "en-orange-socal", destroying the prefix relationship. Setting the rules of canonicalization to take prefixes into account, on the other hand, would be confusing in the extreme, and nobody outside this list would implement it correctly. > Should we change RFC 4647 to say that the order of variants doesn't > count? Are there other aspects of our syntax where the same problem > arises? It seems to happen at least for extensions. Yes, tag matching should allow variants to appear in any order. Unlike variants, canonicalizing extension singletons by alphabetical order makes perfect sense, because extension singletons are semi-arbitrary one-letter identifiers and different classes of extensions (identified by different singletons) aren't expected to be interrelated. > If you want to use a singleton extension, then you have to apply for > it, and once you applied, you would keep you own registry. There would > not be a need to forward interesting ones to the general registry, as > everybody can take the variants from your registry if they need them. > The problem might be that the singleton extensions were imagined for > 'by-topic' extensions, and your registry could end up with all kinds > of extensions. I was a longtime advocate of creating an extension for transcriptions and transliterations, including phonetic alphabets. Now that we have assigned variants for that purpose, however, it would be unwise to go back and create the extension and deprecate the subtags we just created. That is the complete opposite of stability, and it makes us look like we are just shooting in the dark. -- 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 Feb 20 02:04:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJP3B-0002hn-4C; Tue, 20 Feb 2007 02:04:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJP3A-0002hi-B8 for ltru@ietf.org; Tue, 20 Feb 2007 02:04:32 -0500 Received: from mta15.adelphia.net ([68.168.78.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJP37-0007lL-Aa for ltru@ietf.org; Tue, 20 Feb 2007 02:04:31 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070220065223.ILKZ22571.mta15.adelphia.net@DGBP7M81> for ; Tue, 20 Feb 2007 01:52:23 -0500 Message-ID: <00fd01c754bd$5b2fa630$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 19 Feb 2007 23:04:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] Re: "Placeholder" dates in draft Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >>> Would such a placeholder as 6666-06-06, 7777-07-07 or 1111-11-11 >>> break such systems, Stephane?:-) > >> Unfortunately, dates later than 2038 are hard for many systems to >> handle. > > Then it's a good test, like 2106-02-08... Problem is, it's a test of the wrong thing -- how well your OS handles dates, not how your application handles the Registry. -- 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 Feb 20 02:13:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJPBq-0007PT-6U; Tue, 20 Feb 2007 02:13:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJPBn-0007PL-Ld for ltru@ietf.org; Tue, 20 Feb 2007 02:13:27 -0500 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJPBl-0000co-Ey for ltru@ietf.org; Tue, 20 Feb 2007 02:13:26 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070220071325.CJEP14346.mta13.adelphia.net@DGBP7M81> for ; Tue, 20 Feb 2007 02:13:25 -0500 Message-ID: <010301c754be$9d5bb160$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 19 Feb 2007 23:13:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ltru] Re: Erratum ? (upper-case X in numeric character references) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Could we please just bag entities and use UTF-8 in the registry? The > entities are ugly, unreadable, and unnecessary in this modern era of > Unicode. +1. But didn't we already have this discussion at least two or three times before, and it was a showstopper for someone? For example, I thought it turned out we couldn't use UTF-8 if we were going to submit the initial Registry to IANA via an RFC, because RFCs have to be pure ASCII. But yeah, +1. > Some folks on the ietf-languages list have even had trouble submitting > them (using a Web mail system appears to cause interference between > the entities and the mail system's Web pages). That cuts both ways, because not all Web mail systems can handle UTF-8 either. I've had to stop sending UTF-8 em dashes (—) to certain mailing lists because they get corrupted. -- 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 Feb 20 02:18:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJPGy-0001iK-CN; Tue, 20 Feb 2007 02:18:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJPGx-0001hf-0Q for ltru@ietf.org; Tue, 20 Feb 2007 02:18:47 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJPGv-0001l9-O9 for ltru@ietf.org; Tue, 20 Feb 2007 02:18:46 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070220071845.RGBC28666.mta9.adelphia.net@DGBP7M81> for ; Tue, 20 Feb 2007 02:18:45 -0500 Message-ID: <010501c754bf$5c393c10$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 19 Feb 2007 23:18:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Re: Identifying script (or global) variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Hosken wrote: > Even if you went for a domain based approach where do you draw the > line: > > de-1901-fonipa That particular example doesn't work, because "1901" describes a Latin-alphabet orthographic convention which goes straight out the window if the text is converted IPA. > I realise I may have slipped in 2 questions here that I was after > asking. In addition to knowing which order variants can occur, I'm > also not sure whether Latn is required since en has a Latn suppress > script on it. Does adding fonipa require that the Latn reappear or can > it remain suppressed? It is not required to specify "Latn" when using the "fonipa" or "fonupa" variants. Indeed, depending on whom you ask, these variants either imply that the text is written in the Latin script, or imply that it 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 Feb 20 03:24:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJQIK-00006z-Cn; Tue, 20 Feb 2007 03:24:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJQIJ-00006s-Di for ltru@ietf.org; Tue, 20 Feb 2007 03:24:15 -0500 Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJQIF-0006WJ-3Y for ltru@ietf.org; Tue, 20 Feb 2007 03:24:15 -0500 Received: from localhost (spam2.cs.tut.fi [130.230.4.7]) by mail.cs.tut.fi (Postfix) with ESMTP id 5BD6A10AF for ; Tue, 20 Feb 2007 10:23:52 +0200 (EET) Received: from mail.cs.tut.fi ([130.230.4.42]) by localhost (spam2.cs.tut.fi [130.230.4.7]) (amavisd-maia, port 10024) with ESMTP id 14964-05 for ; Tue, 20 Feb 2007 10:23:51 +0200 (EET) Received: from mustatilhi.cs.tut.fi (mustatilhi.cs.tut.fi [130.230.4.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id D7AF61025 for ; Tue, 20 Feb 2007 10:23:51 +0200 (EET) Date: Tue, 20 Feb 2007 10:23:51 +0200 (EET) From: "Jukka K. Korpela" To: LTRU Working Group Subject: Re: [Ltru] Re: Erratum ? (upper-case X in numeric character references) In-Reply-To: <010301c754be$9d5bb160$6401a8c0@DGBP7M81> Message-ID: References: <010301c754be$9d5bb160$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, 19 Feb 2007, Doug Ewell wrote: > That cuts both ways, because not all Web mail systems can handle UTF-8 > either. I've had to stop sending UTF-8 em dashes () to certain mailing lists > because they get corrupted. My experience with webmail systems suggests that _mostly_ they cannot handle anything but the character encoding wired into the software, which is probably not UTF-8. Since webmail is important to many people in many occasions, including travels, international email is not UTF-8 safe, sadly enough. Anything but US-ASCII is more or less risky. -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 04:46:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJRa9-0006qn-AE; Tue, 20 Feb 2007 04:46:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJRa8-0006qe-Iv for ltru@ietf.org; Tue, 20 Feb 2007 04:46:44 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJRa7-0006Ye-7K for ltru@ietf.org; Tue, 20 Feb 2007 04:46:44 -0500 Received: from [62.195.155.247] (helo=[192.168.0.2]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1HJRa41U1U-0002Nz; Tue, 20 Feb 2007 10:46:40 +0100 Message-ID: <45DAC35D.70701@wiktionaryz.org> Date: Tue, 20 Feb 2007 10:46:05 +0100 From: Gerard Meijssen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Jukka K. Korpela" Subject: Re: [Ltru] Re: Erratum ? (upper-case X in numeric character references) References: <010301c754be$9d5bb160$6401a8c0@DGBP7M81> <45DAC0E9.6080307@gmail.com> In-Reply-To: <45DAC0E9.6080307@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:528303289ead4d3089a048dec30d9d30 X-Provags-ID2: V01U2FsdGVkX1+guTeG6A++i4/QbWpCRMLHwX2uPjFh4xsccDg2n/x2byWV22GwBiysDFQ935sLIgWDufiAGnBvGvSIiF+B9Daotlt5XnsIz+zAU6YBGKXb6w== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Gerard Meijssen schreef: > Jukka K. Korpela schreef: >> On Mon, 19 Feb 2007, Doug Ewell wrote: >> >>> That cuts both ways, because not all Web mail systems can handle >>> UTF-8 either. I've had to stop sending UTF-8 em dashes () to >>> certain mailing lists because they get corrupted. >> >> My experience with webmail systems suggests that _mostly_ they cannot >> handle anything but the character encoding wired into the software, >> which is probably not UTF-8. Since webmail is important to many >> people in many occasions, including travels, international email is >> not UTF-8 safe, sadly enough. Anything but US-ASCII is more or less >> risky. >> > Hoi, > The conclusion is that when you have a webmail service provider that > stinks, you have to get another webmail server provider. I user GMAIL > and I am able to have it send e-mails for my other accounts as well. > It really saves me a lot of hassles. The spam filter is really good. > Few false positives. > Thanks, > Gerard > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 06:45:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJTQt-0002om-8q; Tue, 20 Feb 2007 06:45:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJTQs-0002og-L8 for ltru@ietf.org; Tue, 20 Feb 2007 06:45:18 -0500 Received: from mail09.svc.cra.dublin.eircom.net ([159.134.118.25]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJTQr-0002uj-DP for ltru@ietf.org; Tue, 20 Feb 2007 06:45:18 -0500 Received: (qmail 27397 messnum 2883373 invoked from network[194.125.174.18/ts09-018.dublin.indigo.ie]); 20 Feb 2007 11:45:14 -0000 Received: from ts09-018.dublin.indigo.ie (HELO ?194.125.174.18?) (194.125.174.18) by mail09.svc.cra.dublin.eircom.net (qp 27397) with SMTP; 20 Feb 2007 11:45:14 -0000 In-Reply-To: <008201c75470$98773cd0$6401a8c0@DGBP7M81> References: <008201c75470$98773cd0$6401a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: Progress Date: Tue, 20 Feb 2007 11:47:43 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Thanks, Doug. That is progress. mg On 19 Feb 2007, at 21:54, scr=EDobh Doug Ewell: > If nobody has any objections, I'll use 2029-09-09 in future drafts.... - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 10:05:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWYK-0008IC-VT; Tue, 20 Feb 2007 10:05:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWYJ-0008I4-OC for ltru@lists.ietf.org; Tue, 20 Feb 2007 10:05:11 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJWYF-0007dl-91 for ltru@lists.ietf.org; Tue, 20 Feb 2007 10:05:11 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HJWTw-0005Bq-J5 for ltru@lists.ietf.org; Tue, 20 Feb 2007 16:00:40 +0100 Received: from d252013.dialin.hansenet.de ([80.171.252.13]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Feb 2007 16:00:40 +0100 Received: from nobody by d252013.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Feb 2007 16:00:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 20 Feb 2007 15:58:45 +0100 Organization: Lines: 20 Message-ID: <45DB0CA5.3653@xyzzy.claranet.de> References: <45DA1EBB.3DD9@xyzzy.claranet.de> <6.0.0.20.2.20070220113003.04e32730@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252013.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] Re: Erratum ? (upper-case X in numeric character references) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: >> I've now proposed this beast: >> UNICHAR = %x26.23.78 2*6HEXDIG ";" > Just a detail: What about > UNICHAR = "&#" %x78 2*6HEXDIG ";" > Maybe just a tiny bit more readable, but I don't care too much. Nor me. For John's draft I proposed a comment 'starts with "&#x"' for the readability, and kept the %x26 because it then implicitly explains why "&" has to be expressed as "&". In RFC 4646 we have an explicit explanation "ampersand is 26" or similar. Somewhere and somehow it has to be mentioned, but once is of course good enough. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 10:10:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWdW-00012R-SZ; Tue, 20 Feb 2007 10:10:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWdV-00012H-O9 for ltru@lists.ietf.org; Tue, 20 Feb 2007 10:10:33 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJWdU-00006o-Ez for ltru@lists.ietf.org; Tue, 20 Feb 2007 10:10:33 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HJWca-0006xq-6d for ltru@lists.ietf.org; Tue, 20 Feb 2007 16:09:36 +0100 Received: from d252013.dialin.hansenet.de ([80.171.252.13]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Feb 2007 16:09:36 +0100 Received: from nobody by d252013.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Feb 2007 16:09:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 20 Feb 2007 16:07:38 +0100 Organization: Lines: 17 Message-ID: <45DB0EBA.3804@xyzzy.claranet.de> References: <45DA1EBB.3DD9@xyzzy.claranet.de> <6.0.0.20.2.20070220113003.04e32730@localhost> <45DA7606.8010103@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252013.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: Erratum ? (upper-case X in numeric character references) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > entities are ugly, unreadable, and unnecessary in this modern era of > Unicode Unicode is a nice reference charset. Using it directly in plain text OTOH strikes me as bad idea for this decade. Users of the registry need to know what something _should_ be, they're not interested to learn which codepoints their system doesn't support. As far as we know they use PC DOS 3.30 behind a web2mail gateway in a remote area of the Sahara. The registry has still to work for them. Folks would scream when we use a signature as start of the registry. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 10:17:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWjz-0006X8-42; Tue, 20 Feb 2007 10:17:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWjy-0006X3-Rq for ltru@lists.ietf.org; Tue, 20 Feb 2007 10:17:14 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJWjx-0001vT-Iq for ltru@lists.ietf.org; Tue, 20 Feb 2007 10:17:14 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HJWjm-000889-Gy for ltru@lists.ietf.org; Tue, 20 Feb 2007 16:17:04 +0100 Received: from d252013.dialin.hansenet.de ([80.171.252.13]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Feb 2007 16:17:02 +0100 Received: from nobody by d252013.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Feb 2007 16:17:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 20 Feb 2007 16:16:35 +0100 Organization: Lines: 19 Message-ID: <45DB10D3.4BF6@xyzzy.claranet.de> References: <00fd01c754bd$5b2fa630$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252013.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: "Placeholder" dates in draft Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >>> dates later than 2038 are hard for many systems to handle. >> Then it's a good test, like 2106-02-08... > Problem is, it's a test of the wrong thing -- how well your OS > handles dates, not how your application handles the Registry. Point. That argument works also for "NCRs good" vs. "UTF-8 not yet": If users want to see the raw registry on their mobile device it's not the moment to ask them to install some fonts with African click characters or what else first. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 10:24:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWqa-0001Sf-9A; Tue, 20 Feb 2007 10:24:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWqZ-0001Sa-Lg for ltru@ietf.org; Tue, 20 Feb 2007 10:24:03 -0500 Received: from wr-out-0506.google.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJWqY-0003mc-5m for ltru@ietf.org; Tue, 20 Feb 2007 10:24:03 -0500 Received: by wr-out-0506.google.com with SMTP id 55so2828337wri for ; Tue, 20 Feb 2007 07:24:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=RW8tnaWZNlHbfxTNfVLDHlBl61/RufrtabkKqG6SbSefg6TLT/aSIq7x0niTmFSYQ9o19AZzB5pI9zFvo2OOa6iXTBitn0Ra6HAf7ggIJpvcEWSSLBzLui+O+vf5nKcQ7/k76uaQCyDbjJmTI6TsEraWr3Vlv39mdhi/bUq3nxA= Received: by 10.90.102.20 with SMTP id z20mr8719884agb.1171985041893; Tue, 20 Feb 2007 07:24:01 -0800 (PST) Received: by 10.90.50.16 with HTTP; Tue, 20 Feb 2007 07:24:01 -0800 (PST) Message-ID: <30b660a20702200724r223ef18fh25e076bca67d4326@mail.gmail.com> Date: Tue, 20 Feb 2007 07:24:01 -0800 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Identifying script (or global) variants In-Reply-To: <00fb01c754bd$085f6490$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> <6.0.0.20.2.20070220120742.07672b80@localhost> <00fb01c754bd$085f6490$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 72564566c7f6a55a X-Spam-Score: 0.5 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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="===============2105476399==" Errors-To: ltru-bounces@ietf.org --===============2105476399== Content-Type: multipart/alternative; boundary="----=_Part_11587_33296223.1171985041600" ------=_Part_11587_33296223.1171985041600 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I disagree. We don't have any provision for the ordering of variants meaning something different in 4646, and until such time as we do, there is no purpose to allowing arbitrary distinctions by ordering according to the whim of the composer. Now, we should be willing to consider a non-arbitrary ordering, but we would have to build it in to the registry. A simple model would be: In the record for the variant, have a Order field, with values from 0 to 999. If Order does not occur, then the value is defaulted to 500. The canonical order for variants is by ascending Order. Then the "more significant differences" (like polyton) could be given precedence. Mark On 2/19/07, Doug Ewell wrote: > > Martin Duerst wrote: > > > Using alphabetical order would be one solution, but the results may > > look a bit too unnatural. Using 'major before minor' would work in > > general, but in many cases, there will be different opinions. > > People will differ on which variants are more "major" than others. > That's a certainty. > > I don't think it's reasonable to talk about "canonicalizing" tags by > putting the variants in alphabetical order. That would put "boont" > before "fonipa", bot "fonipa" before "scouse", which is completely > arbitrary. > > It could also separate prefixes that include other variants. Let's say > you have a variant "socal" that identifies the Southern California > dialect of English (like, y'know, fer sure dude) and suppose you have > another variant "orange" that identifies the Orange County variant of > "en-socal" and has "en-socal" as its only Prefix. (I don't know of any > uniquely Orange County dialect, but play along.) "Canonicalizing" the > variants in alphabetical order would give "en-orange-socal", destroying > the prefix relationship. Setting the rules of canonicalization to take > prefixes into account, on the other hand, would be confusing in the > extreme, and nobody outside this list would implement it correctly. > > > Should we change RFC 4647 to say that the order of variants doesn't > > count? Are there other aspects of our syntax where the same problem > > arises? It seems to happen at least for extensions. > > Yes, tag matching should allow variants to appear in any order. > > Unlike variants, canonicalizing extension singletons by alphabetical > order makes perfect sense, because extension singletons are > semi-arbitrary one-letter identifiers and different classes of > extensions (identified by different singletons) aren't expected to be > interrelated. > > > If you want to use a singleton extension, then you have to apply for > > it, and once you applied, you would keep you own registry. There would > > not be a need to forward interesting ones to the general registry, as > > everybody can take the variants from your registry if they need them. > > The problem might be that the singleton extensions were imagined for > > 'by-topic' extensions, and your registry could end up with all kinds > > of extensions. > > I was a longtime advocate of creating an extension for transcriptions > and transliterations, including phonetic alphabets. Now that we have > assigned variants for that purpose, however, it would be unwise to go > back and create the extension and deprecate the subtags we just created. > That is the complete opposite of stability, and it makes us look like we > are just shooting in the dark. > > -- > 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_11587_33296223.1171985041600 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I disagree. We don't have any provision for the ordering of variants meaning something different in 4646, and until such time as we do, there is no purpose to allowing arbitrary distinctions by ordering according to the whim of the composer.

Now, we should be willing to consider a non-arbitrary ordering, but we would have to build it in to the registry. A simple model would be:

In the record for the variant, have a Order field, with values from 0 to 999. If Order does not occur, then the value is defaulted to 500. The canonical order for variants is by ascending Order.

Then the "more significant differences" (like polyton) could be given precedence.

Mark

On 2/19/07, Doug Ewell < dewell@adelphia.net> wrote:
Martin Duerst <duerst at it dot aoyama dot ac dot jp> wrote:

> Using alphabetical order would be one solution, but the results may
> look a bit too unnatural. Using 'major before minor' would work in
> general, but in many cases, there will be different opinions.

People will differ on which variants are more "major" than others.
That's a certainty.

I don't think it's reasonable to talk about "canonicalizing" tags by
putting the variants in alphabetical order.  That would put "boont"
before "fonipa", bot "fonipa" before "scouse", which is completely
arbitrary.

It could also separate prefixes that include other variants.  Let's say
you have a variant "socal" that identifies the Southern California
dialect of English (like, y'know, fer sure dude) and suppose you have
another variant "orange" that identifies the Orange County variant of
"en-socal" and has "en-socal" as its only Prefix.  (I don't know of any
uniquely Orange County dialect, but play along.)  "Canonicalizing" the
variants in alphabetical order would give "en-orange-socal", destroying
the prefix relationship.  Setting the rules of canonicalization to take
prefixes into account, on the other hand, would be confusing in the
extreme, and nobody outside this list would implement it correctly.

> Should we change RFC 4647 to say that the order of variants doesn't
> count? Are there other aspects of our syntax where the same problem
> arises? It seems to happen at least for extensions.

Yes, tag matching should allow variants to appear in any order.

Unlike variants, canonicalizing extension singletons by alphabetical
order makes perfect sense, because extension singletons are
semi-arbitrary one-letter identifiers and different classes of
extensions (identified by different singletons) aren't expected to be
interrelated.

> If you want to use a singleton extension, then you have to apply for
> it, and once you applied, you would keep you own registry. There would
> not be a need to forward interesting ones to the general registry, as
> everybody can take the variants from your registry if they need them.
> The problem might be that the singleton extensions were imagined for
> 'by-topic' extensions, and your registry could end up with all kinds
> of extensions.

I was a longtime advocate of creating an extension for transcriptions
and transliterations, including phonetic alphabets.  Now that we have
assigned variants for that purpose, however, it would be unwise to go
back and create the extension and deprecate the subtags we just created.
That is the complete opposite of stability, and it makes us look like we
are just shooting in the dark.

--
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_11587_33296223.1171985041600-- --===============2105476399== 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 --===============2105476399==-- From ltru-bounces@ietf.org Tue Feb 20 10:52:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXHh-0007gO-Od; Tue, 20 Feb 2007 10:52:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXHh-0007fM-20 for ltru@ietf.org; Tue, 20 Feb 2007 10:52:05 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJXHf-0001Sk-QD for ltru@ietf.org; Tue, 20 Feb 2007 10:52:05 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HJXHd-0006b3-VM; Tue, 20 Feb 2007 10:52:02 -0500 Date: Tue, 20 Feb 2007 10:52:01 -0500 To: Mark Davis Subject: Re: [Ltru] Re: Identifying script (or global) variants Message-ID: <20070220155201.GE17709@mercury.ccil.org> References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> <6.0.0.20.2.20070220120742.07672b80@localhost> <00fb01c754bd$085f6490$6401a8c0@DGBP7M81> <30b660a20702200724r223ef18fh25e076bca67d4326@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20702200724r223ef18fh25e076bca67d4326@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > In the record for the variant, have a Order field, with values from 0 to > 999. If Order does not occur, then the value is defaulted to 500. The > canonical order for variants is by ascending Order. Way way overkill. > Then the "more significant differences" (like polyton) could be given > precedence. Y'know, I deny that polytonic is a "more significant" difference at all. The difference in legibility is nearly nil; you can train someone who can read one mode to read the other in about five minutes. Writing polytonic if you only know monotonic is harder, but that's because polytonic has not been functional in Greek for millennia; at the moment it was invented, indeed, it was already obsolete. There are minor technological issues around polytonic rendering, and of course the political significance is huge. If it weren't for the latter point, it would be about as worthwhile giving it a subtag as coding the difference between "Romanian with 's with comma below'" and "Romanian with 's with cedilla'". (All this is a specimen worm from the can that you open if you try to decide in any formal way the relative significance of variant subtags.) -- It was dreary and wearisome. Cold clammy winter still held way in this forsaken country. The only green was the scum of livid weed on the dark greasy surfaces of the sullen waters. Dead grasses and rotting reeds loomed up in the mists like ragged shadows of long-forgotten summers. --"The Passage of the Marshes" http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 11:02:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXRn-0005Ri-8s; Tue, 20 Feb 2007 11:02:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXRm-0005Rd-GU for ltru@ietf.org; Tue, 20 Feb 2007 11:02:30 -0500 Received: from wx-out-0506.google.com ([66.249.82.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJXRl-0004hH-4v for ltru@ietf.org; Tue, 20 Feb 2007 11:02:30 -0500 Received: by wx-out-0506.google.com with SMTP id h31so2170560wxd for ; Tue, 20 Feb 2007 08:02:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=g7O8Z531Dm/njCWBhC67CcUslVfPgwaDoq/1CSgTDQvoR41PmvVa9QUDwfLRh2flkwG0b14TssBKEHcRuTrr6jUSeqSUlmDzEpDAuvtgJxu+PmhwXccuRzo1EdA6hn1yFnhokN/AQeoWAZl7NepU4JX02hXM9p/uEhECXmg5oOo= Received: by 10.90.55.19 with SMTP id d19mr8867082aga.1171987348879; Tue, 20 Feb 2007 08:02:28 -0800 (PST) Received: by 10.90.50.16 with HTTP; Tue, 20 Feb 2007 08:02:28 -0800 (PST) Message-ID: <30b660a20702200802ra45f2c0q13b1c36df17218f9@mail.gmail.com> Date: Tue, 20 Feb 2007 08:02:28 -0800 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: Identifying script (or global) variants In-Reply-To: <20070220155201.GE17709@mercury.ccil.org> MIME-Version: 1.0 References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> <6.0.0.20.2.20070220120742.07672b80@localhost> <00fb01c754bd$085f6490$6401a8c0@DGBP7M81> <30b660a20702200724r223ef18fh25e076bca67d4326@mail.gmail.com> <20070220155201.GE17709@mercury.ccil.org> X-Google-Sender-Auth: a71895f65c0461ba X-Spam-Score: 0.5 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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="===============0212043766==" Errors-To: ltru-bounces@ietf.org --===============0212043766== Content-Type: multipart/alternative; boundary="----=_Part_12731_7520470.1171987348811" ------=_Part_12731_7520470.1171987348811 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Overkill compared to what? Please be more explicit. My main point was that we have a problem with multiple variants, because the ordering doesn't make a difference in 4646, but we don't canonicalize to any order. The simplest way to do that is alphabetical, which I think is fine. Doug wanted something different, so I sketched what something could look like. But I'm fine with alphabetical. Mark On 2/20/07, John Cowan wrote: > > Mark Davis scripsit: > > > In the record for the variant, have a Order field, with values from 0 to > > 999. If Order does not occur, then the value is defaulted to 500. The > > canonical order for variants is by ascending Order. > > Way way overkill. > > > Then the "more significant differences" (like polyton) could be given > > precedence. > > Y'know, I deny that polytonic is a "more significant" difference at all. > The difference in legibility is nearly nil; you can train someone who can > read one mode to read the other in about five minutes. Writing polytonic > if you only know monotonic is harder, but that's because polytonic has > not been functional in Greek for millennia; at the moment it was invented, > indeed, it was already obsolete. > > There are minor technological issues around polytonic rendering, and of > course the political significance is huge. If it weren't for the latter > point, it would be about as worthwhile giving it a subtag as coding the > difference between "Romanian with 's with comma below'" and "Romanian with > 's with cedilla'". > > (All this is a specimen worm from the can that you open if you try to > decide in any formal way the relative significance of variant subtags.) > > -- > It was dreary and wearisome. Cold clammy winter still held way in this > forsaken country. The only green was the scum of livid weed on the dark > greasy surfaces of the sullen waters. Dead grasses and rotting reeds > loomed > up in the mists like ragged shadows of long-forgotten summers. > --"The Passage of the Marshes" http://www.ccil.org/~cowan > -- Mark ------=_Part_12731_7520470.1171987348811 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Overkill compared to what? Please be more explicit.

My main point was that we have a problem with multiple variants, because the ordering doesn't make a difference in 4646, but we don't canonicalize to any order. The simplest way to do that is alphabetical, which I think is fine. Doug wanted something different, so I sketched what something could look like. But I'm fine with alphabetical.

Mark

On 2/20/07, John Cowan <cowan@ccil.org> wrote:
Mark Davis scripsit:

> In the record for the variant, have a Order field, with values from 0 to
> 999. If Order does not occur, then the value is defaulted to 500. The
> canonical order for variants is by ascending Order.

Way way overkill.

> Then the "more significant differences" (like polyton) could be given
> precedence.

Y'know, I deny that polytonic is a "more significant" difference at all.
The difference in legibility is nearly nil; you can train someone who can
read one mode to read the other in about five minutes.  Writing polytonic
if you only know monotonic is harder, but that's because polytonic has
not been functional in Greek for millennia; at the moment it was invented,
indeed, it was already obsolete.

There are minor technological issues around polytonic rendering, and of
course the political significance is huge.  If it weren't for the latter
point, it would be about as worthwhile giving it a subtag as coding the
difference between "Romanian with 's with comma below'" and "Romanian with
's with cedilla'".

(All this is a specimen worm from the can that you open if you try to
decide in any formal way the relative significance of variant subtags.)

--
It was dreary and wearisome.  Cold clammy winter still held way in this
forsaken country.  The only green was the scum of livid weed on the dark
greasy surfaces of the sullen waters.  Dead grasses and rotting reeds loomed
up in the mists like ragged shadows of long-forgotten summers.
        --"The Passage of the Marshes"           http://www.ccil.org/~cowan



--
Mark ------=_Part_12731_7520470.1171987348811-- --===============0212043766== 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 --===============0212043766==-- From ltru-bounces@ietf.org Tue Feb 20 11:30:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXsh-0002WO-9x; Tue, 20 Feb 2007 11:30:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXsf-0002PB-9W for ltru@lists.ietf.org; Tue, 20 Feb 2007 11:30:17 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJXsd-0002ux-MV for ltru@lists.ietf.org; Tue, 20 Feb 2007 11:30:17 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HJXsT-0002ZY-A0 for ltru@lists.ietf.org; Tue, 20 Feb 2007 17:30:05 +0100 Received: from d252013.dialin.hansenet.de ([80.171.252.13]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Feb 2007 17:30:05 +0100 Received: from nobody by d252013.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Feb 2007 17:30:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 20 Feb 2007 17:29:36 +0100 Organization: Lines: 16 Message-ID: <45DB21F0.3947@xyzzy.claranet.de> References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> <6.0.0.20.2.20070220120742.07672b80@localhost> <00fb01c754bd$085f6490$6401a8c0@DGBP7M81> <30b660a20702200724r223ef18fh25e076bca67d4326@mail.gmail.com> <20070220155201.GE17709@mercury.ccil.org> <30b660a20702200802ra45f2c0q13b1c36df17218f9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252013.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] Re: Identifying script (or global) variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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'm fine with alphabetical. I'm not for the reason stated by Doug: There can be a variant of a variant. Constructed example: The 'coastal' dialect of 'valencia', with prefix ca-valencia, results in ca-valencia-coastal. You can't swap that saying ca-coastal-valencia without giving up on the prefix. The concept of "variant of variant" isn't used yet, but it could be. For independent variants let folks just pick an order reflecting their idea of importance, tags are truncated right to left if necessary. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 11:36:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXyX-0007Kx-OH; Tue, 20 Feb 2007 11:36:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXyW-0007Kr-EN for ltru@ietf.org; Tue, 20 Feb 2007 11:36:20 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJXyT-0004kt-5e for ltru@ietf.org; Tue, 20 Feb 2007 11:36:20 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HJXyS-0001m3-QE; Tue, 20 Feb 2007 11:36:16 -0500 Date: Tue, 20 Feb 2007 11:36:16 -0500 To: Mark Davis Subject: Re: [Ltru] Re: Identifying script (or global) variants Message-ID: <20070220163616.GH17709@mercury.ccil.org> References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> <6.0.0.20.2.20070220120742.07672b80@localhost> <00fb01c754bd$085f6490$6401a8c0@DGBP7M81> <30b660a20702200724r223ef18fh25e076bca67d4326@mail.gmail.com> <20070220155201.GE17709@mercury.ccil.org> <30b660a20702200802ra45f2c0q13b1c36df17218f9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20702200802ra45f2c0q13b1c36df17218f9@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > Overkill compared to what? Please be more explicit. Compared with any other option, including doing nothing. > My main point was that we have a problem with multiple variants, I'm willing to be convinced that we have a problem, but I don't see any problem yet. > because the ordering doesn't make a difference in 4646, There is no statement to that effect in 4646, which simply says that multiple variants are allowed, without saying that order matters or doesn't matter semantically. (Order does, of course, matter to the algorithms in 4647.) > but we don't canonicalize to any order. If order matters in some particular case, we provide for it by encouraging the use of a Prefix: field on the secondary variant that specifies the appropriate primary variant(s). Otherwise, I don't see any reason to fix what isn't broken. -- Values of beeta will give rise to dom! John Cowan (5th/6th edition 'mv' said this if you tried http://www.ccil.org/~cowan to rename '.' or '..' entries; see cowan@ccil.org http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 13:48:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJa2g-0001Qn-Rl; Tue, 20 Feb 2007 13:48:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJa2f-0001Q2-EW for ltru@ietf.org; Tue, 20 Feb 2007 13:48:45 -0500 Received: from wx-out-0506.google.com ([66.249.82.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJa2e-0001Yp-2Z for ltru@ietf.org; Tue, 20 Feb 2007 13:48:45 -0500 Received: by wx-out-0506.google.com with SMTP id h31so2216219wxd for ; Tue, 20 Feb 2007 10:48:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=JsfjSh4uWrn2lT8BfYPqgHmZSdZPsDilujiKNnC5juWCOjFPK2h/edL1/jHiI3G85/WIkXeYrmFK5xWMWxFHCy4E7pps8VY/dXU9mr3/fxA0e3cjgK3BPl8/sVrc6dAzjDoiSGdHyKYohBu90afTPHDGlSv9ls20iUsilCdKE0c= Received: by 10.90.84.17 with SMTP id h17mr9154618agb.1171997323686; Tue, 20 Feb 2007 10:48:43 -0800 (PST) Received: by 10.90.50.16 with HTTP; Tue, 20 Feb 2007 10:48:43 -0800 (PST) Message-ID: <30b660a20702201048p21d0d217n74334c736b3ee40d@mail.gmail.com> Date: Tue, 20 Feb 2007 10:48:43 -0800 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: Identifying script (or global) variants In-Reply-To: <20070220163616.GH17709@mercury.ccil.org> MIME-Version: 1.0 References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> <6.0.0.20.2.20070220120742.07672b80@localhost> <00fb01c754bd$085f6490$6401a8c0@DGBP7M81> <30b660a20702200724r223ef18fh25e076bca67d4326@mail.gmail.com> <20070220155201.GE17709@mercury.ccil.org> <30b660a20702200802ra45f2c0q13b1c36df17218f9@mail.gmail.com> <20070220163616.GH17709@mercury.ccil.org> X-Google-Sender-Auth: 6bbffe85227e73a5 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2062559012==" Errors-To: ltru-bounces@ietf.org --===============2062559012== Content-Type: multipart/alternative; boundary="----=_Part_19296_32810577.1171997323329" ------=_Part_19296_32810577.1171997323329 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Since people's understanding of the text differs from yours, we have at least a problem in clarity of the text. I think we do have a problem. Not a huge one, since the variants are little used, but insofar as they are used, someone looking at the text of RFC and the registry should be able to tell whether en-VARIANT1-VARIANTA is the same as en-VARIANTA-VARIANT1 or not. - If they are not intended to be the same, then what is the difference between them? Which one should be used where? - If they are intended to be different, then the canonicalization should be the same, so that spurious differences can be erased in comparison. If the standard is silent on these issues, then we just have a muddle. Mark On 2/20/07, John Cowan wrote: > > Mark Davis scripsit: > > > Overkill compared to what? Please be more explicit. > > Compared with any other option, including doing nothing. > > > My main point was that we have a problem with multiple variants, > > I'm willing to be convinced that we have a problem, but I don't see > any problem yet. > > > because the ordering doesn't make a difference in 4646, > > There is no statement to that effect in 4646, which simply says that > multiple variants are allowed, without saying that order matters > or doesn't matter semantically. (Order does, of course, matter > to the algorithms in 4647.) > > > but we don't canonicalize to any order. > > If order matters in some particular case, we provide for it by encouraging > the use of a Prefix: field on the secondary variant that specifies the > appropriate primary variant(s). Otherwise, I don't see any reason to > fix what isn't broken. > > -- > Values of beeta will give rise to dom! John Cowan > (5th/6th edition 'mv' said this if you tried http://www.ccil.org/~cowan > to rename '.' or '..' entries; see cowan@ccil.org > http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) > -- Mark ------=_Part_19296_32810577.1171997323329 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Since people's understanding of the text differs from yours, we have at least a problem in clarity of the text.

I think we do have a problem. Not a huge one, since the variants are little used, but insofar as they are used, someone looking at the text of RFC and the registry should be able to tell whether
en-VARIANT1-VARIANTA
is the same as
en-VARIANTA-VARIANT1
or not.
  • If they are not intended to be the same, then what is the difference between them? Which one should be used where?
  • If they are intended to be different, then the canonicalization should be the same, so that spurious differences can be erased in comparison.
If the standard is silent on these issues, then we just have a muddle.

Mark

On 2/20/07, John Cowan < cowan@ccil.org> wrote:
Mark Davis scripsit:

> Overkill compared to what? Please be more explicit.

Compared with any other option, including doing nothing.

> My main point was that we have a problem with multiple variants,

I'm willing to be convinced that we have a problem, but I don't see
any problem yet.

> because the ordering doesn't make a difference in 4646,

There is no statement to that effect in 4646, which simply says that
multiple variants are allowed, without saying that order matters
or doesn't matter semantically.  (Order does, of course, matter
to the algorithms in 4647.)

> but we don't canonicalize to any order.

If order matters in some particular case, we provide for it by encouraging
the use of a Prefix: field on the secondary variant that specifies the
appropriate primary variant(s).  Otherwise, I don't see any reason to
fix what isn't broken.

--
Values of beeta will give rise to dom!          John Cowan
(5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan
to rename '.' or '..' entries; see               cowan@ccil.org
http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)



--
Mark ------=_Part_19296_32810577.1171997323329-- --===============2062559012== 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 --===============2062559012==-- From ltru-bounces@ietf.org Tue Feb 20 15:03:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbCU-0005JR-Ae; Tue, 20 Feb 2007 15:02:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbCT-0005JL-AO for ltru@ietf.org; Tue, 20 Feb 2007 15:02:57 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJbCQ-0000KM-SE for ltru@ietf.org; Tue, 20 Feb 2007 15:02:57 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l1KK2HwS032537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Feb 2007 12:02:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=j5n06tgKzHIkELPd+fCMUG5E3l3XWAxrY+DEfu1vDUO+zZJiKrLcnQoMKsxGYc1a Message-ID: <45DB53C6.1040300@yahoo-inc.com> Date: Tue, 20 Feb 2007 12:02:14 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Re: Identifying script (or global) variants References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> <6.0.0.20.2.20070220120742.07672b80@localhost> <00fb01c754bd$085f6490$6401a8c0@DGBP7M81> <30b660a20702200724r223ef18fh25e076bca67d4326@mail.gmail.com> <20070220155201.GE17709@mercury.ccil.org> <30b660a20702200802ra45f2c0q13b1c36df17218f9@mail.gmail.com> <20070220163616.GH17709@mercury.ccil.org> <30b660a20702201048p21d0d217n74334c736b3ee40d@mail.gmail.com> In-Reply-To: <30b660a20702201048p21d0d217n74334c736b3ee40d@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Mark Davis wrote: > Since people's understanding of the text differs from yours, we have at > least a problem in clarity of the text. > > I think we do have a problem. Not a huge one, since the variants are > little used, but insofar as they are used, someone looking at the text > of RFC and the registry should be able to tell whether > en-VARIANT1-VARIANTA > is the same as > en-VARIANTA-VARIANT1 > or not. > This is a reason why general variants were hotly debated in the "3066bis" era. Specific variants, such as the German orthographic variations, tend to have clearly defined interactions. In fact, they are defined in ways that prevent usage together and Section 2.2.5 says: "Most variants that share a prefix are mutually exclusive. ... 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." The general purpose variants are problematic because they introduce this sort of ordering problem where none exists with specific variants. The problem in this thread is that it is unclear if a given general variant is "wider" or "narrower" than a given specific variant. RFC 4647 basically says: put your subtags in order from widest to narrowest. For some, IPA seems wider than scouse. For others, the reverse is true. One solution would be to specify that general variants "SHOULD" appear before specific variants: en-fonipa-scouse While it is true that multiple general variations might occur in a single tag, that tag will border on incomprehensibility. Personally, I think we should have banned general variants and should have sent the transcription folks off to write an extension (so I could be free to ignore it). Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 20 17:10:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJdC8-0001M6-I8; Tue, 20 Feb 2007 17:10:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJdC6-0001L4-S4 for ltru@ietf.org; Tue, 20 Feb 2007 17:10:42 -0500 Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJdC5-0004ee-B2 for ltru@ietf.org; Tue, 20 Feb 2007 17:10:42 -0500 Received: by wr-out-0506.google.com with SMTP id 55so3020250wri for ; Tue, 20 Feb 2007 14:10:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=WyxYNYfrXHbzeAxA+iSBGJ71dkt2XeljZsbS51AHGsBBJ027eAr+DvdV2m+xZXiohbnGC0gf7MAWlDAG1YGB5aAblsn//iQ654danFn8FU0qLyMuZy8C/EKl6RXcNAh893KCQ4NZ0dXiCMKyF9LdTnkTqA+5YE8dNXjCvY3PCRI= Received: by 10.90.55.19 with SMTP id d19mr9400092aga.1172009440793; Tue, 20 Feb 2007 14:10:40 -0800 (PST) Received: by 10.90.50.16 with HTTP; Tue, 20 Feb 2007 14:10:40 -0800 (PST) Message-ID: <30b660a20702201410s40726958pd0d192407d8510ef@mail.gmail.com> Date: Tue, 20 Feb 2007 14:10:40 -0800 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: Identifying script (or global) variants In-Reply-To: <45DB53C6.1040300@yahoo-inc.com> MIME-Version: 1.0 References: <45DA54A0.3080007@sil.org> <6.0.0.20.2.20070220120742.07672b80@localhost> <00fb01c754bd$085f6490$6401a8c0@DGBP7M81> <30b660a20702200724r223ef18fh25e076bca67d4326@mail.gmail.com> <20070220155201.GE17709@mercury.ccil.org> <30b660a20702200802ra45f2c0q13b1c36df17218f9@mail.gmail.com> <20070220163616.GH17709@mercury.ccil.org> <30b660a20702201048p21d0d217n74334c736b3ee40d@mail.gmail.com> <45DB53C6.1040300@yahoo-inc.com> X-Google-Sender-Auth: 37220b151bdc2064 X-Spam-Score: 0.3 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1501667290==" Errors-To: ltru-bounces@ietf.org --===============1501667290== Content-Type: multipart/alternative; boundary="----=_Part_2241_10417708.1172009440579" ------=_Part_2241_10417708.1172009440579 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline In that case, I'd make canonicalization put all general variants before all specific variants, and within those two groups, put them in alphabetical order. >Personally, I think we should have banned general variants and should have sent the transcription folks off to write an extension (so I could be free to ignore it). Personally, I think that the transcriptions are reasonable. Had we known that the Script RA was going to exclude them (in my opinion, for no good reason, given such goofiness as Latf), we would have reserved some subtags for registering them in the script position, like 4 characters starting with a letter and ending with a digit. Mark On 2/20/07, Addison Phillips wrote: > > Mark Davis wrote: > > Since people's understanding of the text differs from yours, we have at > > least a problem in clarity of the text. > > > > I think we do have a problem. Not a huge one, since the variants are > > little used, but insofar as they are used, someone looking at the text > > of RFC and the registry should be able to tell whether > > en-VARIANT1-VARIANTA > > is the same as > > en-VARIANTA-VARIANT1 > > or not. > > > > > This is a reason why general variants were hotly debated in the > "3066bis" era. Specific variants, such as the German orthographic > variations, tend to have clearly defined interactions. In fact, they are > defined in ways that prevent usage together and Section 2.2.5 says: > > "Most variants that share a prefix are mutually exclusive. ... 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." > > The general purpose variants are problematic because they introduce this > sort of ordering problem where none exists with specific variants. > > The problem in this thread is that it is unclear if a given general > variant is "wider" or "narrower" than a given specific variant. RFC 4647 > basically says: put your subtags in order from widest to narrowest. For > some, IPA seems wider than scouse. For others, the reverse is true. > > One solution would be to specify that general variants "SHOULD" appear > before specific variants: > > en-fonipa-scouse > > While it is true that multiple general variations might occur in a > single tag, that tag will border on incomprehensibility. Personally, I > think we should have banned general variants and should have sent the > transcription folks off to write an extension (so I could be free to > ignore it). > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > -- Mark ------=_Part_2241_10417708.1172009440579 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In that case, I'd make canonicalization put all general variants before all specific variants, and within those two groups, put them in alphabetical order.

>Personally, I
think we should have banned general variants and should have sent the
transcription folks off to write an extension (so I could be free to
ignore it).

Personally, I think that the transcriptions are reasonable. Had we known that the Script RA was going to  exclude them (in my opinion, for no good reason, given such goofiness as Latf), we would have reserved some subtags for registering them in the script position, like 4 characters starting with a letter and ending with a digit.

Mark

On 2/20/07, Addison Phillips <addison@yahoo-inc.com> wrote:
Mark Davis wrote:
> Since people's understanding of the text differs from yours, we have at
> least a problem in clarity of the text.
>
> I think we do have a problem. Not a huge one, since the variants are
> little used, but insofar as they are used, someone looking at the text
> of RFC and the registry should be able to tell whether
> en-VARIANT1-VARIANTA
> is the same as
> en-VARIANTA-VARIANT1
> or not.
>


This is a reason why general variants were hotly debated in the
"3066bis" era. Specific variants, such as the German orthographic
variations, tend to have clearly defined interactions. In fact, they are
defined in ways that prevent usage together and Section 2.2.5 says:

"Most variants that share a prefix are mutually exclusive. ... 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."

The general purpose variants are problematic because they introduce this
sort of ordering problem where none exists with specific variants.

The problem in this thread is that it is unclear if a given general
variant is "wider" or "narrower" than a given specific variant. RFC 4647
basically says: put your subtags in order from widest to narrowest. For
some, IPA seems wider than scouse. For others, the reverse is true.

One solution would be to specify that general variants "SHOULD" appear
before specific variants:

    en-fonipa-scouse

While it is true that multiple general variations might occur in a
single tag, that tag will border on incomprehensibility. Personally, I
think we should have banned general variants and should have sent the
transcription folks off to write an extension (so I could be free to
ignore it).

Addison

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

Internationalization is an architecture.
It is not a feature.





--
Mark ------=_Part_2241_10417708.1172009440579-- --===============1501667290== 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 --===============1501667290==-- From ltru-bounces@ietf.org Wed Feb 21 02:15:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJlgy-0003Lr-1B; Wed, 21 Feb 2007 02:15:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJlgx-0003Lm-Fc for ltru@ietf.org; Wed, 21 Feb 2007 02:15:07 -0500 Received: from mta15.adelphia.net ([68.168.78.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJlgu-0008GQ-4Q for ltru@ietf.org; Wed, 21 Feb 2007 02:15:07 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070221070255.EAOS22571.mta15.adelphia.net@DGBP7M81> for ; Wed, 21 Feb 2007 02:02:55 -0500 Message-ID: <005f01c75587$feba8110$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 20 Feb 2007 23:14:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Ltru] Re: Identifying script (or global) variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > My main point was that we have a problem with multiple variants, > because the ordering doesn't make a difference in 4646, but we don't > canonicalize to any order. The simplest way to do that is > alphabetical, which I think is fine. Doug wanted something different, > so I sketched what something could look like. But I'm fine with > alphabetical. I may have missed something here. If you mean "canonicalize" in the sense of something a computer or other process does for purposes of comparison, that can be completely invisible to humans, then alphabetical is fine. It is certainly better than adding a bunch of arbitrary-looking integers, that are bound to attract the same criticisms as the similarly conceived Unicode combining classes. If you mean to specify a canonical order for subtags to *appear* within a tag, then neither alphabetical nor "general before specific" will work, because alphabetical breaks the prefix rule (as Frank and I said) and language-specific variants may be more important to protect from right-truncation than generic ones. Example 1: two specific variants ca-valencia-coastal ca-coastal-valencia As Frank pointed out, the second is not equivalent to the first if "coastal" has a Prefix of "ca-valencia". Example 2: one generic, one specific sl-nedis-fonipa sl-fonipa-nedis Since these two variants are unrelated, the order makes no real difference, so processes can swap them internally with no ill effect. Frank is right, though, that users may choose different orderings based on their idea of importance, and cannot in any case be expected to write variants in alphabetical order. Example 3 (hypothetical): two generic variants en-scouse-pitman en-pitman-scouse Like Example 1, the subtags can be swapped only if they are unrelated, never if one variant is part of the Prefix of the other. In the case of generic variants, this seems likely. Note the imaginary variant "pitman", intended to be generic since many languages could theoretically be written in Pitman shorthand. -- 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 Feb 21 10:17:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtDg-0004EX-4m; Wed, 21 Feb 2007 10:17:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtDf-0004Dh-3h for ltru@lists.ietf.org; Wed, 21 Feb 2007 10:17:23 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJtDb-0006TX-Me for ltru@lists.ietf.org; Wed, 21 Feb 2007 10:17:23 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HJtDL-0006I4-Cr for ltru@lists.ietf.org; Wed, 21 Feb 2007 16:17:03 +0100 Received: from d253235.dialin.hansenet.de ([80.171.253.235]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Feb 2007 16:17:03 +0100 Received: from nobody by d253235.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Feb 2007 16:17:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 21 Feb 2007 16:16:41 +0100 Organization: Lines: 8 Message-ID: <45DC6259.2EC@xyzzy.claranet.de> References: <005901c752c1$3f5fb0b0$6401a8c0@DGBP7M81> <45DA54A0.3080007@sil.org> <6.0.0.20.2.20070220120742.07672b80@localhost> <00fb01c754bd$085f6490$6401a8c0@DGBP7M81> <30b660a20702200724r223ef18fh25e076bca67d4326@mail.gmail.com> <20070220155201.GE17709@mercury.ccil.org> <30b660a20702200802ra45f2c0q13b1c36df17218f9@mail.gmail.com> <20070220163616.GH17709@mercury.ccil.org> <30b660a20702201048p21d0d217n74334c736b3ee40d@mail.gmail.com> <45DB53C6.1040300@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253235.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Ltru] Re: Identifying script (or global) variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Personally, I think we should have banned general variants and should > have sent the transcription folks off to write an extension (so I could > be free to ignore it). +1 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 21 10:20:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtGd-00055Y-Rm; Wed, 21 Feb 2007 10:20:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtGd-00055M-0N for ltru@ietf.org; Wed, 21 Feb 2007 10:20:27 -0500 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJtGb-0007B0-It for ltru@ietf.org; Wed, 21 Feb 2007 10:20:26 -0500 Received: by wx-out-0506.google.com with SMTP id h31so2498329wxd for ; Wed, 21 Feb 2007 07:20:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=AJ4J2KDfT7JXPurx910hXHW+KdaMSmCh2vKjDmp9Snuy3g5l0E4Mp1yZlUSb+tRPJ3Ct9XaVhqdEfYe2hNjTMHO4lTYwNcG74jZN0bBaM0oVXt0Va7vseyrY4jF1iKC2CgK53dmNlmqr/K6R7ely7+zF2ojMf4fRdF/b+5FyMXs= Received: by 10.90.113.20 with SMTP id l20mr10141592agc.1172071225132; Wed, 21 Feb 2007 07:20:25 -0800 (PST) Received: by 10.90.50.16 with HTTP; Wed, 21 Feb 2007 07:20:24 -0800 (PST) Message-ID: <30b660a20702210720h241e0605u1f3bef2e6004c634@mail.gmail.com> Date: Wed, 21 Feb 2007 07:20:24 -0800 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Identifying script (or global) variants In-Reply-To: <005f01c75587$feba8110$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <005f01c75587$feba8110$6401a8c0@DGBP7M81> X-Google-Sender-Auth: f311a0f0e0322883 X-Spam-Score: 0.1 (/) 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="===============1259115216==" Errors-To: ltru-bounces@ietf.org --===============1259115216== Content-Type: multipart/alternative; boundary="----=_Part_22262_17049517.1172071224861" ------=_Part_22262_17049517.1172071224861 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline It appears that you didn't see my message of Feb 20, 2007 2:10 PM On 2/20/07, Doug Ewell wrote: > > Mark Davis wrote: > > > My main point was that we have a problem with multiple variants, > > because the ordering doesn't make a difference in 4646, but we don't > > canonicalize to any order. The simplest way to do that is > > alphabetical, which I think is fine. Doug wanted something different, > > so I sketched what something could look like. But I'm fine with > > alphabetical. > > I may have missed something here. If you mean "canonicalize" in the > sense of something a computer or other process does for purposes of > comparison, that can be completely invisible to humans, then > alphabetical is fine. It is certainly better than adding a bunch of > arbitrary-looking integers, that are bound to attract the same > criticisms as the similarly conceived Unicode combining classes. > > If you mean to specify a canonical order for subtags to *appear* within > a tag, then neither alphabetical nor "general before specific" will > work, because alphabetical breaks the prefix rule (as Frank and I said) > and language-specific variants may be more important to protect from > right-truncation than generic ones. > > Example 1: two specific variants > > ca-valencia-coastal > ca-coastal-valencia > > As Frank pointed out, the second is not equivalent to the first if > "coastal" has a Prefix of "ca-valencia". > > Example 2: one generic, one specific > > sl-nedis-fonipa > sl-fonipa-nedis > > Since these two variants are unrelated, the order makes no real > difference, so processes can swap them internally with no ill effect. > Frank is right, though, that users may choose different orderings based > on their idea of importance, and cannot in any case be expected to write > variants in alphabetical order. > > Example 3 (hypothetical): two generic variants > > en-scouse-pitman > en-pitman-scouse > > Like Example 1, the subtags can be swapped only if they are unrelated, > never if one variant is part of the Prefix of the other. In the case of > generic variants, this seems likely. Note the imaginary variant > "pitman", intended to be generic since many languages could > theoretically be written in Pitman shorthand. > > -- > 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_22262_17049517.1172071224861 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline It appears that you didn't see my message of Feb 20, 2007 2:10 PM

On 2/20/07, Doug Ewell <dewell@adelphia.net > wrote:
Mark Davis <mark dot davis at icu dash project dot org> wrote:

> My main point was that we have a problem with multiple variants,
> because the ordering doesn't make a difference in 4646, but we don't
> canonicalize to any order. The simplest way to do that is
> alphabetical, which I think is fine. Doug wanted something different,
> so I sketched what something could look like. But I'm fine with
> alphabetical.

I may have missed something here.  If you mean "canonicalize" in the
sense of something a computer or other process does for purposes of
comparison, that can be completely invisible to humans, then
alphabetical is fine.  It is certainly better than adding a bunch of
arbitrary-looking integers, that are bound to attract the same
criticisms as the similarly conceived Unicode combining classes.

If you mean to specify a canonical order for subtags to *appear* within
a tag, then neither alphabetical nor "general before specific" will
work, because alphabetical breaks the prefix rule (as Frank and I said)
and language-specific variants may be more important to protect from
right-truncation than generic ones.

Example 1: two specific variants

    ca-valencia-coastal
    ca-coastal-valencia

As Frank pointed out, the second is not equivalent to the first if
"coastal" has a Prefix of "ca-valencia".

Example 2: one generic, one specific

    sl-nedis-fonipa
    sl-fonipa-nedis

Since these two variants are unrelated, the order makes no real
difference, so processes can swap them internally with no ill effect.
Frank is right, though, that users may choose different orderings based
on their idea of importance, and cannot in any case be expected to write
variants in alphabetical order.

Example 3 (hypothetical): two generic variants

    en-scouse-pitman
    en-pitman-scouse

Like Example 1, the subtags can be swapped only if they are unrelated,
never if one variant is part of the Prefix of the other.  In the case of
generic variants, this seems likely.  Note the imaginary variant
"pitman", intended to be generic since many languages could
theoretically be written in Pitman shorthand.

--
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_22262_17049517.1172071224861-- --===============1259115216== 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 --===============1259115216==-- From ltru-bounces@ietf.org Thu Feb 22 09:26:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKEt3-0002O7-Uk; Thu, 22 Feb 2007 09:25:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKEt2-0002No-HQ for ltru@ietf.org; Thu, 22 Feb 2007 09:25:32 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HKEt0-0004U9-4i for ltru@ietf.org; Thu, 22 Feb 2007 09:25:32 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070222142523.WCKN22452.mta10.adelphia.net@DGBP7M81>; Thu, 22 Feb 2007 09:25:23 -0500 Message-ID: <005d01c7568d$4aacbb00$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <005f01c75587$feba8110$6401a8c0@DGBP7M81> <30b660a20702210720h241e0605u1f3bef2e6004c634@mail.gmail.com> Subject: Re: [Ltru] Re: Identifying script (or global) variants Date: Thu, 22 Feb 2007 06:25:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Mark Davis wrote: > It appears that you didn't see my message of Feb 20, 2007 2:10 PM in which he wrote: > In that case, I'd make canonicalization put all general variants > before all specific variants, and within those two groups, put them in > alphabetical order. That doesn't solve the problem of rearranging "ca-valencia-coastal" to "ca-coastal-valencia", where "coastal" is assumed to be a subvariant of "ca-valencia" and has that as its Prefix. All of the variants involved here are specific, not general, and so belong to the same alphabetically sorted group. I assume that "specific" and "general" variants are defined as those that do and do not have a Prefix, respectively. What I don't understand is why all this machinery is preferable to a statement in RFC 4646bis that for matching purposes ONLY, the order of variants should be ignored. -- 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 Feb 22 10:08:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKFYh-0003iL-9F; Thu, 22 Feb 2007 10:08:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKFYg-0003iD-H1 for ltru@ietf.org; Thu, 22 Feb 2007 10:08:34 -0500 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKFYd-0005uX-N3 for ltru@ietf.org; Thu, 22 Feb 2007 10:08:34 -0500 Received: by wx-out-0506.google.com with SMTP id h31so202500wxd for ; Thu, 22 Feb 2007 07:08:30 -0800 (PST) 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=KbXQqtVEVBFbHMsupeNtVVbYIYIxr0eDkmgDS2Qvbbo4b6246UK1YL9zTM4QKwCVEFOnrqUw5qJHcOTFWChBWRq1vPjuq+PdmgLcpkMqZULAI6LlukCdhvUUoigSkHHjRPwx5l65d/WlGuid8uWIJlNRcr/TbqADpPH/XTYxDoQ= 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=hyN4mxbxmZkebhnd+Marj5CcyKLcjXygfL6+L955+KtMCh3s33VGcUjV1hIcQnmiX/zztqqGipPQeIxKnWGbICk8JeWQUX7R03V8A8f43z7lR7AFFpdtvg9gUJ8cCwIFs/HAqx0cJ2sWy5X/rNwES85GgEXLY7epw4VxOaN1jEQ= Received: by 10.90.49.19 with SMTP id w19mr502219agw.1172156910576; Thu, 22 Feb 2007 07:08:30 -0800 (PST) Received: by 10.90.50.16 with HTTP; Thu, 22 Feb 2007 07:08:30 -0800 (PST) Message-ID: <30b660a20702220708v53ca3d08ra72faa5f7f5f3ce@mail.gmail.com> Date: Thu, 22 Feb 2007 07:08:30 -0800 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Identifying script (or global) variants In-Reply-To: <005d01c7568d$4aacbb00$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <005f01c75587$feba8110$6401a8c0@DGBP7M81> <30b660a20702210720h241e0605u1f3bef2e6004c634@mail.gmail.com> <005d01c7568d$4aacbb00$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 52ff8648418fc9b0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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="===============1415700338==" Errors-To: ltru-bounces@ietf.org --===============1415700338== Content-Type: multipart/alternative; boundary="----=_Part_29491_2309292.1172156910504" ------=_Part_29491_2309292.1172156910504 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline But that is what canonicalization is for; to put the tag into a form that can be matched. If the items are out of order, then 4747 won't match correctly. If there is a problem with the process I suggested, then we work to fix the process. Here is another round (informal language at this point): V3. canonicalization sorts the variants in the following way. Given two variants A and B, apply each of the following steps to A and B, then B and A, stopping when there is a hit. 1. if A has no prefix and B has a prefix, A comes before B 2. if A is part of a prefix (given the previous non-variant subtags) for B, A comes before B 3. if A is alphabetically before B, A comes before B. This also exposes a couple of issues with multiple variants that we haven't yet accounted for: - We don't have a validity constraint that a variant can't occur twice (as we do for extensions); we should add it. - We also should add the constraint on registration that we can't have a cycle, eg that we can't have A as a valid prefix for B and B a valid prefix for A. Mark On 2/22/07, Doug Ewell wrote: > > Mark Davis wrote: > > > It appears that you didn't see my message of Feb 20, 2007 2:10 PM > > in which he wrote: > > > In that case, I'd make canonicalization put all general variants > > before all specific variants, and within those two groups, put them in > > alphabetical order. > > That doesn't solve the problem of rearranging "ca-valencia-coastal" to > "ca-coastal-valencia", where "coastal" is assumed to be a subvariant of > "ca-valencia" and has that as its Prefix. All of the variants involved > here are specific, not general, and so belong to the same alphabetically > sorted group. > > I assume that "specific" and "general" variants are defined as those > that do and do not have a Prefix, respectively. > > What I don't understand is why all this machinery is preferable to a > statement in RFC 4646bis that for matching purposes ONLY, the order of > variants should be ignored. > > -- > 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_29491_2309292.1172156910504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline But that is what canonicalization is for; to put the tag into a form that can be matched. If the items are out of order, then 4747 won't match correctly. If there is a problem with the process I suggested, then we work to fix the process. Here is another round (informal language at this point):

V3. canonicalization sorts the variants in the following way. Given two variants A and B, apply each of the following steps to A and B, then B and A, stopping when there is a hit.
 1. if A has no prefix and B has a prefix, A comes before B
2. if A is part of a prefix (given the previous non-variant subtags) for B, A comes before B
3. if A is alphabetically before B, A comes before B.

This also exposes a couple of issues with multiple variants that we haven't yet accounted for:
  • We don't have a validity constraint that a variant can't occur twice (as we do for extensions); we should add it.
  • We also should add the constraint on registration that we can't have a cycle, eg that we can't have A as a valid prefix for B and B a valid prefix for A.

Mark

On 2/22/07, Doug Ewell <dewell@adelphia.net> wrote:
Mark Davis wrote:

> It appears that you didn't see my message of Feb 20, 2007 2:10 PM

in which he wrote:

> In that case, I'd make canonicalization put all general variants
> before all specific variants, and within those two groups, put them in
> alphabetical order.

That doesn't solve the problem of rearranging "ca-valencia-coastal" to
"ca-coastal-valencia", where "coastal" is assumed to be a subvariant of
"ca-valencia" and has that as its Prefix.  All of the variants involved
here are specific, not general, and so belong to the same alphabetically
sorted group.

I assume that "specific" and "general" variants are defined as those
that do and do not have a Prefix, respectively.

What I don't understand is why all this machinery is preferable to a
statement in RFC 4646bis that for matching purposes ONLY, the order of
variants should be ignored.

--
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_29491_2309292.1172156910504-- --===============1415700338== 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 --===============1415700338==-- From ltru-bounces@ietf.org Thu Feb 22 17:25:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKMNo-0001qh-S8; Thu, 22 Feb 2007 17:25:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKMNn-0001q4-Ah for ltru@ietf.org; Thu, 22 Feb 2007 17:25:47 -0500 Received: from netc-relay-2m.netcourrier.com ([194.158.104.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKMNm-0007fR-0C for ltru@ietf.org; Thu, 22 Feb 2007 17:25:47 -0500 Received: from netcourrier.com (netcourrier-3m.netcourrier.com [194.158.104.103]) by netc-relay-2m.netcourrier.com (Postfix) with SMTP id F081026E3B for ; Thu, 22 Feb 2007 23:25:26 +0100 (CET) Received: from [85.68.10.110] by netcourrier-3m.netcourrier.com via html interface From: Nicolas Krebs To: ltru@ietf.org Subject: Re: [Ltru] Comorian and other issues Date: Thu, 22 Feb 2007 23:25:26 +0100 Mime-Version: 1.0 X-Priority: 5 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 >Date: Fri, 16 Feb 2007 02:19:19 -0500 >To: Nicolas Krebs >CC: ltru=40ietf.org >Subject: Re: =5BLtru=5D Comorian and other issues >From: John Cowan > >Nicolas Krebs scripsit: > >> After partial review of urn:ietf:id:draft-ietf-ltru-4645bis-01 ( >> http://tools.ietf.org/html/draft-ietf-ltru-4645bis-01 ), i found some >> issue, a question and our old friend -western. > >Generic note: These considerations are appropriate for the ISO 693-3 >Registration Authority, not for ietf-languages; we just clone what >they provide. My comments are not authoritative. So ltru wg can not fix bug of ISO 639-3 ? = >> 3 Comorian > >=5Bsnip=5D > >> If i understand correctly, swb is the encompass language, and the >> other are dialect. Then: > >That's not the view of 639-3, which treats the four as separate and >distinct languages. Comorian (swb) is the largest, but it's not >considered to encompass the others. So swb correspond to specific (1) Comorian of people who said that there i= s = no specific (1) Comorian and only one generic (1) Comorian ? = 1: i use deliberately two word of urn:ietf:id:draft-ietf-ltru-4645bis-0, = correct me if i use it wrongly. = _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Feb 23 03:23:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKVhY-0003sv-Fc; Fri, 23 Feb 2007 03:22:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKVhX-0003rV-3t for ltru@ietf.org; Fri, 23 Feb 2007 03:22:47 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKVhV-00081d-Bq for ltru@ietf.org; Fri, 23 Feb 2007 03:22:47 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l1N8MYTn026554 for ; Fri, 23 Feb 2007 17:22:34 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0df8_031393ee_c317_11db_9e83_0014221fa3c9; Fri, 23 Feb 2007 17:22:33 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49884) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 23 Feb 2007 17:21:37 +0900 Message-Id: <6.0.0.20.2.20070223124711.10930b90@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 23 Feb 2007 12:49:06 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Identifying script (or global) variants In-Reply-To: <005d01c7568d$4aacbb00$6401a8c0@DGBP7M81> References: <005f01c75587$feba8110$6401a8c0@DGBP7M81> <30b660a20702210720h241e0605u1f3bef2e6004c634@mail.gmail.com> <005d01c7568d$4aacbb00$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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 23:25 07/02/22, Doug Ewell wrote: >What I don't understand is why all this machinery is preferable to a statement in RFC 4646bis that for matching purposes ONLY, the order of variants should be ignored. We should not change RFC 4647 by a little note in RFC 4646bis. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Feb 23 09:49:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKbjN-0001xh-B6; Fri, 23 Feb 2007 09:49:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKbjM-0001x1-Fu for ltru@ietf.org; Fri, 23 Feb 2007 09:49:04 -0500 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKbjK-0006fQ-4t for ltru@ietf.org; Fri, 23 Feb 2007 09:49:04 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070223143656.IKSR22571.mta15.adelphia.net@DGBP7M81> for ; Fri, 23 Feb 2007 09:36:56 -0500 Message-ID: <003501c75759$c0fcb040$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 23 Feb 2007 06:48:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Re: Comorian and other issues X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Nicolas Krebs wrote: > So ltru wg can not fix bug of ISO 639-3 ? Not only do we not "fix" them, it's not even our job to decide that they are "bugs." We don't pretend to know more about Comorian, or any other language, than the experts who maintain the ISO standard. IIRC, our deviation from external standards is limited to the following: 1. We don't add a new subtag corresponding to a new code element that would duplicate or conflict with other subtags. 2. We deprecate, but do not delete, an existing subtag corresponding to a deleted or withdrawn code element. -- 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 Feb 23 11:45:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKdXj-0000pH-LV; Fri, 23 Feb 2007 11:45:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKdXi-0000p9-8z for ltru@ietf.org; Fri, 23 Feb 2007 11:45:10 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKdXg-0007my-NY for ltru@ietf.org; Fri, 23 Feb 2007 11:45:10 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070223164506.ITRK28666.mta9.adelphia.net@DGBP7M81>; Fri, 23 Feb 2007 11:45:06 -0500 Message-ID: <005501c75769$f9d1d750$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 23 Feb 2007 08:45:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: [Ltru] Re: Identifying script (or global) variants X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > But that is what canonicalization is for; to put the tag into a form > that can be matched. If the items are out of order, then 4747 won't > match correctly. I'd prefer if we talked about users writing tags and RFC 4647 processors rearranging them into an order that can be matched correctly. > If there is a problem with the process I suggested, then we work to > fix the process. Here is another round (informal language at this > point): > > V3. canonicalization sorts the variants in the following way. Given > two variants A and B, apply each of the following steps to A and B, > then B and A, stopping when there is a hit. > 1. if A has no prefix and B has a prefix, A comes before B > 2. if A is part of a prefix (given the previous non-variant subtags) > for B, A comes before B > 3. if A is alphabetically before B, A comes before B. I think 2 needs to come before 1 somehow, but otherwise this is a noticeable improvement. I still have my doubts that users will know to write "en-fonipa-scouse" instead of "en-scouse-fonipa". The natural way to think of this is "English, Scouse dialect, written in IPA." > This also exposes a couple of issues with multiple variants that we > haven't yet accounted for: > > We don't have a validity constraint that a variant can't occur twice > (as we do for extensions); we should add it. I'm pretty sure we used to have a clause, though not a MUST, that tag generators SHOULD NOT generate duplicate variants such as "en-boont-boont". It makes sense to me, given that we forbid "en-a-aaa-a-bbb", and I don't remember why it was removed. > We also should add the constraint on registration that we can't have a > cycle, eg that we can't have A as a valid prefix for B and B a valid > prefix for A. +1. I think ietf-languages would be careful to check for this anyway, but putting it in the RFC would ensure that they don't forget in case things get complex. As a general reminder, we are not getting any closer to our January 2007 deadlines and should be conservative about giving ourselves more work items. -- 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 Feb 24 06:53:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKvSP-0001X8-VK; Sat, 24 Feb 2007 06:52:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKvSO-0001X3-V2 for ltru@ietf.org; Sat, 24 Feb 2007 06:52:52 -0500 Received: from netc-relay-1m.netcourrier.com ([194.158.104.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKvSJ-0003Sv-MF for ltru@ietf.org; Sat, 24 Feb 2007 06:52:52 -0500 Received: from netcourrier.com (netcourrier-3m.netcourrier.com [194.158.104.103]) by netc-relay-1m.netcourrier.com (Postfix) with SMTP id 997FB38BA2 for ; Sat, 24 Feb 2007 12:52:24 +0100 (CET) Received: from [85.68.10.110] by netcourrier-3m.netcourrier.com via html interface From: Nicolas Krebs To: ltru@ietf.org Subject: Re: [Ltru] Re: Comorian and other issues Date: Sat, 24 Feb 2007 12:52:24 +0100 Mime-Version: 1.0 X-Priority: 5 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org >From: =22Doug Ewell=22 >To: =22LTRU Working Group=22 >Date: Fri, 23 Feb 2007 06:48:59 -0800 >Subject: =5BLtru=5D Re: Comorian and other issues > >Nicolas Krebs wrote: > >> So ltru wg can not fix bug of ISO 639-3 ? > >Not only do we not =22fix=22 them, it's not even our job to decide that t= hey = >are =22bugs.=22 = Understoud. Then thanks for the three replies of you and John Cowan, = and end of thread. = _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Feb 24 13:09:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL1Ju-0002CM-7C; Sat, 24 Feb 2007 13:08:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL1Jt-0002AI-0p for ltru@ietf.org; Sat, 24 Feb 2007 13:08:29 -0500 Received: from mail17.svc.cra.dublin.eircom.net ([159.134.118.216]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HL1Jq-0005Xx-OR for ltru@ietf.org; Sat, 24 Feb 2007 13:08:29 -0500 Received: (qmail 85478 messnum 5071761 invoked from network[194.125.205.86/ts07-086.dublin.indigo.ie]); 24 Feb 2007 18:08:20 -0000 Received: from ts07-086.dublin.indigo.ie (HELO ?194.125.205.86?) (194.125.205.86) by mail17.svc.cra.dublin.eircom.net (qp 85478) with SMTP; 24 Feb 2007 18:08:20 -0000 In-Reply-To: <005501c75769$f9d1d750$6401a8c0@DGBP7M81> References: <005501c75769$f9d1d750$6401a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: Identifying script (or global) variants Date: Sat, 24 Feb 2007 18:10:41 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 23 Feb 2007, at 16:45, scr=EDobh Doug Ewell: >> ... > The natural way to think of this is "English, Scouse dialect, =20 > written in IPA." I agree with the above observation. > As a general reminder, we are not getting any closer to our January =20= > 2007 deadlines and should be conservative about giving ourselves =20 > more work items. Again, I agree with the above. mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Feb 26 09:33:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLguU-0004jX-5Q; Mon, 26 Feb 2007 09:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLguT-0004jO-HV for ltru@lists.ietf.org; Mon, 26 Feb 2007 09:33:01 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLguS-0000wq-0H for ltru@lists.ietf.org; Mon, 26 Feb 2007 09:33:01 -0500 Received: from [62.195.155.247] (helo=[192.168.0.2]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1HLguG3jIt-000591; Mon, 26 Feb 2007 15:32:57 +0100 Message-ID: <45E2EF6B.8080804@wiktionaryz.org> Date: Mon, 26 Feb 2007 15:32:11 +0100 From: Gerard Meijssen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: "Placeholder" dates in draft Registry Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:528303289ead4d3089a048dec30d9d30 X-Provags-ID2: V01U2FsdGVkX19PMjKLef6gDQ9CGnR8fBECv1ATJpCEy02h2Qd sj0Skvst0jg18LWoc9Z2OibHrVMO+qFnTvVCOiz9BIt69Oyz2J 9X6HYOvct/nu6J9yRMzbQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hoi, There is some sense to using only the standard Latin characters standard numbers. It means very much that you do restrict yourself on how you describe languages. In the ISO-639-3 there are words for languages with characters that are outside of this. A good example is ||Gana. This is the official label. There are alternate names, G||ana, G||ana-Khwe, Gxana, Gxanna, Dxana, Kanakhoe. Some of these would serve well where the current placeholder for the name is awful. The "pipe" character kills the potential for many automated functions. It is not even the character that does indicate the click sound. IMHO it is a bad choice for what is essentially a list of codes and labels that indicates languages. In many of what I have read people try to read all kinds of things in the codes that are used. It is a human thing to do. However, again in my honest opinion, it is horrible, there are codes that give me a chuckle because what such a good means to me ... in Dutch. When codes are just that, something small referring to something complex that is used for identification, it makes no difference if it says uk or eng or fr or de. The point is, as a human you should not want to read anything in the code itself. With ISO-639-1 and -2 it was possible to know most codes without having to look them up. With the 7000+ of the ISO-639-3 it is much harder and with the ISO-639-6 it will be impossible. ISO-639-6 will be good in that it recognises the existing codes of the ISO-639-1, 2 and 3. The argument here; they are codes do not try to read any meaning in them. The same is true for the names of the entities the codes refer to, they are labels they should fit certain restraints and the use of characters like the "|" is wrong/not helpful. Thanks, GerardM Frank Ellermann schreef: > Doug Ewell wrote: > > >>>> dates later than 2038 are hard for many systems to handle. >>>> > > >>> Then it's a good test, like 2106-02-08... >>> > > >> Problem is, it's a test of the wrong thing -- how well your OS >> handles dates, not how your application handles the Registry. >> > > Point. > > That argument works also for "NCRs good" vs. "UTF-8 not yet": > > If users want to see the raw registry on their mobile device > it's not the moment to ask them to install some fonts with > African click characters or what else first. > > Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Feb 26 20:09:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLqpi-0004Si-BA; Mon, 26 Feb 2007 20:08:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLqDk-0004Wr-4L for ltru@ietf.org; Mon, 26 Feb 2007 19:29:32 -0500 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLqDc-0005g8-Hp for ltru@ietf.org; Mon, 26 Feb 2007 19:29:32 -0500 Received: by wr-out-0506.google.com with SMTP id 58so1785998wri for ; Mon, 26 Feb 2007 16:29:24 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K9p+VXV/b4KZG6l4Bys6V9Qvq6/gPxHcFoPG7V7pF1WhgvPpX1OMNSj/IGb7v1XrL/eRZYRujDMsbmrr3Cv3m3T7kX7KbtSiFvlWfQTDtK9x4ZrMUAoyi/05ElS88W1Tj9rZ4f6bj1lbpySmXs7oL37XtInJk8iLRhjb5PvhVNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z/Kdmy5tYoyTyQ5lyTR3wmHRD5T4YW/Dr7e148fPwal7FJTppspwmBqIWZ2oleunrF9b9wx8Pdzunbee30tiSs4/F/b8xGbbaCKl7vnXVHe8z2ksEZlwuZ1RqA54k4TqHrhSDfwr6pudM3WbuNP36647AWzkNDgj+Mzgw/mUe1A= Received: by 10.90.120.6 with SMTP id s6mr5652815agc.1172536164285; Mon, 26 Feb 2007 16:29:24 -0800 (PST) Received: by 10.90.75.9 with HTTP; Mon, 26 Feb 2007 16:29:24 -0800 (PST) Message-ID: Date: Mon, 26 Feb 2007 19:29:24 -0500 From: "Bill Fenner" To: "McDonald, Ira" Subject: Re: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Ta g MIB) to Proposed Standard In-Reply-To: <789E617C880666438EDEE30C2A3E8D100105A5E6@mailsrvnt05.enet.sharplabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <789E617C880666438EDEE30C2A3E8D100105A5E6@mailsrvnt05.enet.sharplabs.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Mon, 26 Feb 2007 20:06:58 -0500 Cc: ietf-languages@iana.org, Doug Ewell , LTRU Working Group , ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 2/10/07, McDonald, Ira wrote: > With respect to max length of 60, the public MIBs that > I'm aware of often use 63 octets Do you have any pointers? I searched my MIB object database for objects named "*Language*" or with DESCRIPTIONS with "Language" inside, and only got the IP-MROUTE-MIB and MALLOC-MIB ones. The MALLOC-MIB one was interesting, since it uses IPMROUTE-STD-MIB::LanguageTag(1..94). Thanks, Bill _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Feb 26 21:52:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLsRe-0001dz-Jd; Mon, 26 Feb 2007 21:52:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLsRd-0001dt-7g for ltru@ietf.org; Mon, 26 Feb 2007 21:52:01 -0500 Received: from mta8.adelphia.net ([68.168.78.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLsRb-0008EV-V8 for ltru@ietf.org; Mon, 26 Feb 2007 21:52:01 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070227022620.XBTI22452.mta10.adelphia.net@DGBP7M81>; Mon, 26 Feb 2007 21:26:20 -0500 Message-ID: <001901c75a16$ac85f8f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 26 Feb 2007 18:26:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] Re: "Placeholder" dates in draft Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Gerard Meijssen wrote: > There is some sense to using only the standard Latin characters > standard numbers. It means very much that you do restrict yourself on > how you describe languages. In the ISO-639-3 there are words for > languages with characters that are outside of this. A good example is > ||Gana. This is the official label. There are alternate names, G||ana, > G||ana-Khwe, Gxana, Gxanna, Dxana, Kanakhoe. Some of these would serve > well where the current placeholder for the name is awful. The "pipe" > character kills the potential for many automated functions. It is not > even the character that does indicate the click sound. IMHO it is a > bad choice for what is essentially a list of codes and labels that > indicates languages. Look again. There are no vertical bars anywhere in the ISO 639-3 data. The description associated with code element "gnk" is "//Gana", with two forward slashes. Other plain-ASCII characters used for click languages include ! and =. The draft for RFC 4645bis uses the ISO 639-3 names. -- 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 Feb 27 02:30:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLwmV-00052x-Mf; Tue, 27 Feb 2007 02:29:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLwmT-00052e-Q9 for ltru@ietf.org; Tue, 27 Feb 2007 02:29:50 -0500 Received: from an-out-0708.google.com ([209.85.132.247]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLwmP-0003gH-ML for ltru@ietf.org; Tue, 27 Feb 2007 02:29:49 -0500 Received: by an-out-0708.google.com with SMTP id d30so1207795and for ; Mon, 26 Feb 2007 23:29:43 -0800 (PST) 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=bWMDa4oTLNjH2aL9QV3NFuehBUxy8P4KIYAdrcE5NsP+yoevkcyWiLo3/BBt8oaQfcpW17ZykMbJbAp7+0mRv3mgM4afWAQ7yTIYlgdd5+V5gMAXX8Vyc9aG0WZuoX32/eyunrEa5DBnJSE8LWvpLqZxtKQRrVEZxQFKm9BY1HM= 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=MPAMsyxXw8g1sSxDMgQswy0dGQ+vV9OGPn5XRaYJG0MxiVrV9+mYfkJef1bKvL5sV9LHkvxxAtF5m2sFfW/zWej81nNJqpEEKh5d4wnSj0I1Wg9SNw9r1gZgmVYH20GRvk3FQffeRawaREQ0SILGzCfdC0t+7JoPTIkXpVlZ/QE= Received: by 10.114.182.1 with SMTP id e1mr292855waf.1172561380184; Mon, 26 Feb 2007 23:29:40 -0800 (PST) Received: by 10.114.161.8 with HTTP; Mon, 26 Feb 2007 23:29:40 -0800 (PST) Message-ID: <41a006820702262329j2b78bed0s6ebfb5adac4441c@mail.gmail.com> Date: Tue, 27 Feb 2007 08:29:40 +0100 From: "Gerard Meijssen" To: "Doug Ewell" In-Reply-To: <001901c75a16$ac85f8f0$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <001901c75a16$ac85f8f0$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 4b77b0c1978ff9e0 X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: LTRU Working Group Subject: [Ltru] Re: "Placeholder" dates in draft Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1366029998==" Errors-To: ltru-bounces@ietf.org --===============1366029998== Content-Type: multipart/alternative; boundary="----=_Part_4800_16977040.1172561380129" ------=_Part_4800_16977040.1172561380129 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi, I did look again and http://www.ethnologue.com/show_language.asp?code=gnk gives you a ||Gana not //Gana. Given that Ethnologue IS the registrar for ISO-639-3, it is reasonable to expect that their information is authoritative. Thanks, Gerard On 2/27/07, Doug Ewell wrote: > > Gerard Meijssen wrote: > > > There is some sense to using only the standard Latin characters > > standard numbers. It means very much that you do restrict yourself on > > how you describe languages. In the ISO-639-3 there are words for > > languages with characters that are outside of this. A good example is > > ||Gana. This is the official label. There are alternate names, G||ana, > > G||ana-Khwe, Gxana, Gxanna, Dxana, Kanakhoe. Some of these would serve > > well where the current placeholder for the name is awful. The "pipe" > > character kills the potential for many automated functions. It is not > > even the character that does indicate the click sound. IMHO it is a > > bad choice for what is essentially a list of codes and labels that > > indicates languages. > > Look again. There are no vertical bars anywhere in the ISO 639-3 data. > The description associated with code element "gnk" is "//Gana", with two > forward slashes. Other plain-ASCII characters used for click languages > include ! and =. The draft for RFC 4645bis uses the ISO 639-3 names. > > -- > 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 > > ------=_Part_4800_16977040.1172561380129 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi,
I did look again and
http://www.ethnologue.com/show_language.asp?code=gnk gives you a ||Gana
not //Gana. Given that Ethnologue IS the registrar for ISO-639-3, it is
reasonable to expect that their information is authoritative.
Thanks,
    Gerard


On 2/27/07, Doug Ewell <dewell@adelphia.net> wrote:
Gerard Meijssen <gerardm at wiktionaryz dot org> wrote:

> There is some sense to using only the standard Latin characters
> standard numbers. It means very much that you do restrict yourself on
> how you describe languages. In the ISO-639-3 there are words for
> languages with characters that are outside of this. A good example is
> ||Gana. This is the official label. There are alternate names, G||ana,
> G||ana-Khwe, Gxana, Gxanna, Dxana, Kanakhoe. Some of these would serve
> well where the current placeholder for the name is awful. The "pipe"
> character kills the potential for many automated functions. It is not
> even the character that does indicate the click sound. IMHO it is a
> bad choice for what is essentially a list of codes and labels that
> indicates languages.

Look again.  There are no vertical bars anywhere in the ISO 639-3 data.
The description associated with code element "gnk" is "//Gana", with two
forward slashes.  Other plain-ASCII characters used for click languages
include ! and =.  The draft for RFC 4645bis uses the ISO 639-3 names.

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


------=_Part_4800_16977040.1172561380129-- --===============1366029998== 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 --===============1366029998==-- From ltru-bounces@ietf.org Tue Feb 27 02:46:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLx2l-0001Zn-Hn; Tue, 27 Feb 2007 02:46:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLx2k-0001ZU-5S for ltru@ietf.org; Tue, 27 Feb 2007 02:46:38 -0500 Received: from mta16.mail.adelphia.net ([68.168.78.211] helo=mta16.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLx2f-0004Du-QC for ltru@ietf.org; Tue, 27 Feb 2007 02:46:38 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070227074627.UFJN3107.mta16.adelphia.net@DGBP7M81>; Tue, 27 Feb 2007 02:46:27 -0500 Message-ID: <002501c75a43$634e6820$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <001901c75a16$ac85f8f0$6401a8c0@DGBP7M81> <45E3DD61.7010406@gmail.com> Date: Mon, 26 Feb 2007 23:46:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Gerard Meijssen Subject: [Ltru] Re: "Placeholder" dates in draft Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Gerard Meijssen wrote: > I did look again and > http://www.ethnologue.com/show_language.asp?code=gnk gives you a > ||Gana not //Gana. Given that Ethnologue IS the registrar for > ISO-639-3, it is reasonable to expect that their information is > authoritative. The authoritative ISO 639-3 data is at http://www.sil.org/iso639-3/. The Registration Authority for ISO 639-3 is SIL International (not "Ethnologue," which is the name of a reference work published by SIL). The two projects do not always agree 100% on names. -- 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 Feb 27 02:58:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxER-0001Io-Hm; Tue, 27 Feb 2007 02:58:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxEQ-0001Id-Rz for ltru@ietf.org; Tue, 27 Feb 2007 02:58:42 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLxEO-0005k3-Ld for ltru@ietf.org; Tue, 27 Feb 2007 02:58:42 -0500 Received: by ug-out-1314.google.com with SMTP id 72so962639ugd for ; Mon, 26 Feb 2007 23:58:40 -0800 (PST) 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=mN69gK/BTUW6JnC95QOPGOHqpk8CAKoy/IjMjOt9nqZxRjw7juaWCXMXDvuGvHuBiur2t2EW5BagX3NcXCWHc+MFw/be7jfjwnq6o80pdoLo318NGC/zrxvini8z/IBB7/I/jH+c6SUMYaXFKIZbxeBp9/5MHpz3+Rt7hFCvWNU= 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=YYaW6ADkvBXhyZxjkqs+StK9aQDRIQcPUG7BVXXJvZuEjLg55ZGtlxSH5kmbpopg7qXen6Pik7UKh/Osc8w8hZox3pxzO+EmXje1uLaIrQ8Yic3S7VnI15ghFBoKf9C9YUD2crELoAE8xsn6Q5JXhExwqvy15WGQs46oZMNF1s0= Received: by 10.114.179.1 with SMTP id b1mr2462224waf.1172563112744; Mon, 26 Feb 2007 23:58:32 -0800 (PST) Received: by 10.114.161.8 with HTTP; Mon, 26 Feb 2007 23:58:32 -0800 (PST) Message-ID: <41a006820702262358l43958fd3m4dc53e06625bde71@mail.gmail.com> Date: Tue, 27 Feb 2007 08:58:32 +0100 From: "Gerard Meijssen" To: "Doug Ewell" In-Reply-To: <002501c75a43$634e6820$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <001901c75a16$ac85f8f0$6401a8c0@DGBP7M81> <45E3DD61.7010406@gmail.com> <002501c75a43$634e6820$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 280390ccefd50f3a X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: LTRU Working Group Subject: [Ltru] Re: "Placeholder" dates in draft Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0020095143==" Errors-To: ltru-bounces@ietf.org --===============0020095143== Content-Type: multipart/alternative; boundary="----=_Part_5116_14898754.1172563112697" ------=_Part_5116_14898754.1172563112697 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi, When you want to have people adopt Standards, it is essential that there is no discrepancy between these two bodies of work. It is a marketing disaster for the Standard when you have to use a rationalisation like "Ethnologue is not the standard, the standard is http://www.sil.org/iso639-3/ here". It is a well known fact that the ISO-639-3 is based on Ethnologue and that SIL is the registrar. It is reasonable to expect that these is a good relation between the two. Using the "|" is not the character that should be used in the first place. Thanks, Gerard On 2/27/07, Doug Ewell wrote: > > Gerard Meijssen wrote: > > > I did look again and > > http://www.ethnologue.com/show_language.asp?code=gnk gives you a > > ||Gana not //Gana. Given that Ethnologue IS the registrar for > > ISO-639-3, it is reasonable to expect that their information is > > authoritative. > > The authoritative ISO 639-3 data is at http://www.sil.org/iso639-3/. > The Registration Authority for ISO 639-3 is SIL International (not > "Ethnologue," which is the name of a reference work published by SIL). > The two projects do not always agree 100% on names. > > -- > 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 > > ------=_Part_5116_14898754.1172563112697 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi,
When you want to have people adopt Standards, it is essential that there is no discrepancy between these two bodies of work. It is a marketing disaster for the Standard when you have to use a rationalisation like "Ethnologue is not the standard, the standard is http://www.sil.org/iso639-3/ here".

It is a well known fact that the ISO-639-3 is based on Ethnologue and that SIL is the registrar. It is reasonable to expect that these is a good relation between the two. Using the "|" is not the character that should be used in the first place.

Thanks,
    Gerard

On 2/27/07, Doug Ewell <dewell@adelphia.net> wrote:
Gerard Meijssen <gerard dot meijssen at gmail dot com> wrote:

> I did look again and
> http://www.ethnologue.com/show_language.asp?code=gnk gives you a
> ||Gana not //Gana. Given that Ethnologue IS the registrar for
> ISO-639-3, it is reasonable to expect that their information is
> authoritative.

The authoritative ISO 639-3 data is at http://www.sil.org/iso639-3/.
The Registration Authority for ISO 639-3 is SIL International (not
"Ethnologue," which is the name of a reference work published by SIL).
The two projects do not always agree 100% on names.

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


------=_Part_5116_14898754.1172563112697-- --===============0020095143== 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 --===============0020095143==-- From ltru-bounces@ietf.org Tue Feb 27 03:11:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxQN-00053g-9B; Tue, 27 Feb 2007 03:11:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxQL-00053Y-Rf for ltru@ietf.org; Tue, 27 Feb 2007 03:11:01 -0500 Received: from mta15.adelphia.net ([68.168.78.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLxQK-0007Mx-Ga for ltru@ietf.org; Tue, 27 Feb 2007 03:11:01 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070227075854.ZGEQ22571.mta15.adelphia.net@DGBP7M81>; Tue, 27 Feb 2007 02:58:54 -0500 Message-ID: <003001c75a46$d0d85ec0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <001901c75a16$ac85f8f0$6401a8c0@DGBP7M81> <45E3DD61.7010406@gmail.com> <002501c75a43$634e6820$6401a8c0@DGBP7M81> <41a006820702262357o3d2ef494s9b5e2ad7cd91b9a@mail.gmail.com> Date: Tue, 27 Feb 2007 00:10:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: GerardM Subject: [Ltru] Re: "Placeholder" dates in draft Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org GerardM wrote: > When you want to have people adopt Standards, it is essential that > there is no discrepancy between these two bodies of work. It is a > marketing disaster for the Standard when you have to use a > rationalisation like "Ethnologue is not the standard, the standard is > http://www.sil.org/iso639-3/ here". Ethnologue is not the standard. In preparing RFC 4645bis to use subtags based on ISO 639-3 code elements, I am planning to use the official ISO 639-3 data, not the data that was used as initial input to ISO 639-3. Talk to Peter about marketing ISO 639-3. I'm concerned with getting the data into the Registry properly. > It is a well known fact that the ISO-639-3 is based on Ethnologue and > that SIL is the registrar. It is reasonable to expect that these is a > good relation between the two. Using the "|" is not the character that > should be used in the first place. Why do you suppose the vertical bars were changed to forward slashes? Possibly to avoid the problem with vertical bars that you complained about in the first place? -- 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 Feb 27 03:37:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxpP-0005ni-Fm; Tue, 27 Feb 2007 03:36:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxpO-0005nL-Qk for ltru@ietf.org; Tue, 27 Feb 2007 03:36:55 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLxpN-0001Gt-7j for ltru@ietf.org; Tue, 27 Feb 2007 03:36:54 -0500 Received: by ug-out-1314.google.com with SMTP id 72so968394ugd for ; Tue, 27 Feb 2007 00:36:52 -0800 (PST) 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=KFznwgYIdI4IUVrPWD+Av97Qx3Qil72pRFLnz8kZhui4tLouQQxEkgM62qAHFxTt6dh0cpB8dMYbFPRfCQBH9fERmSfM2iCSKL298Ta6Z2gVLqh3uwZsudzRaRnMKr35qSnpVJ9I3vW0dRDC2G9w7m4sS2Wo6JSBIPganDFuBf0= 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=aYdHhROI7h8kIYrmdBpYABYlsabCeGiJwbR/oBdHTF6H698nHbkhE8bP1lj/MOUhSf+xO44LWKS/8pR8PNXvYyP3xKzOi8E2s302/R1FpVKRrKaeC5PZmbVhMcROvnrvWRpcl0cpW/4JA4dnmH1AnRcB5iflhEJEvaAOScYK0WA= Received: by 10.114.202.15 with SMTP id z15mr1290010waf.1172565411473; Tue, 27 Feb 2007 00:36:51 -0800 (PST) Received: by 10.114.161.8 with HTTP; Tue, 27 Feb 2007 00:36:51 -0800 (PST) Message-ID: <41a006820702270036y54918b6cw6d65f406b4f2d60@mail.gmail.com> Date: Tue, 27 Feb 2007 09:36:51 +0100 From: "Gerard Meijssen" To: "Doug Ewell" In-Reply-To: <003001c75a46$d0d85ec0$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <001901c75a16$ac85f8f0$6401a8c0@DGBP7M81> <45E3DD61.7010406@gmail.com> <002501c75a43$634e6820$6401a8c0@DGBP7M81> <41a006820702262357o3d2ef494s9b5e2ad7cd91b9a@mail.gmail.com> <003001c75a46$d0d85ec0$6401a8c0@DGBP7M81> X-Google-Sender-Auth: c72d7a08eddfee3d X-Spam-Score: 0.5 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: LTRU Working Group Subject: [Ltru] Re: "Placeholder" dates in draft Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0763505702==" Errors-To: ltru-bounces@ietf.org --===============0763505702== Content-Type: multipart/alternative; boundary="----=_Part_5884_20006791.1172565411428" ------=_Part_5884_20006791.1172565411428 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi, When each and every one of us do not take the marketing of this work serious, the standard will not be taken more serious than it is. With only 15% of the content of the Internet tagged at all and most of that tagged incorrectly we are not doing a good job. By looking at these numbers I can not come to a different conclusion. When you say that you are busy getting the data in the registry properly, you in effect assume that the registry will reflect the standard. The expectation raised is as reliable as mine that Ethnologue and ISO-639-3 are in sync. I do appreciate and expect that you will do a good job. There are huge benefits possible when content is tagged correctly. At this moment we do not reach the tipping point where this is true. There is this open source project called Shtooka, they record pronunciations in the flacc format; these sound files allow for the integration of the meta-data. What would be easier than having it tagged with the correct codes based on the language indicated by the speaker ... It was not even considered. We just do not have the necessary traction. The standard just does not have enough relevance. This is partly because "the marketing is for others to do" while it will really work best if we all give it some priority and make it a part of what we do. Thanks, Gerard On 2/27/07, Doug Ewell wrote: > > GerardM wrote: > > > When you want to have people adopt Standards, it is essential that > > there is no discrepancy between these two bodies of work. It is a > > marketing disaster for the Standard when you have to use a > > rationalisation like "Ethnologue is not the standard, the standard is > > http://www.sil.org/iso639-3/ here". > > Ethnologue is not the standard. In preparing RFC 4645bis to use subtags > based on ISO 639-3 code elements, I am planning to use the official ISO > 639-3 data, not the data that was used as initial input to ISO 639-3. > > Talk to Peter about marketing ISO 639-3. I'm concerned with getting the > data into the Registry properly. > > > It is a well known fact that the ISO-639-3 is based on Ethnologue and > > that SIL is the registrar. It is reasonable to expect that these is a > > good relation between the two. Using the "|" is not the character that > > should be used in the first place. > > Why do you suppose the vertical bars were changed to forward slashes? > Possibly to avoid the problem with vertical bars that you complained > about in the first place? > > -- > 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 > > ------=_Part_5884_20006791.1172565411428 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi,
When each and every one of us do not take the marketing of this work serious, the standard will not be taken more serious than it is. With only 15% of the content of the Internet tagged at all and most of that tagged incorrectly we are not doing a good job. By looking at these numbers I can not come to a different conclusion.

When you say that you are busy getting the data in the registry properly, you in effect assume that the registry will reflect the standard. The expectation raised is as reliable as mine that Ethnologue and ISO-639-3 are in sync. I do appreciate and expect that you will do a good job.

There are huge benefits possible when content is tagged correctly. At this moment we do not reach the tipping point where this is true. There is this open source project called Shtooka, they record pronunciations in the flacc format; these sound files allow for the integration of the meta-data. What would be easier than having it tagged with the correct codes based on the language indicated by the speaker ... It was not even considered. We just do not have the necessary traction. The standard just does not have enough relevance. This is partly because "the marketing is for others to do" while it will really work best if we all give it some priority and make it a part of what we do.

Thanks,
    Gerard

On 2/27/07, Doug Ewell <dewell@adelphia.net> wrote:
GerardM wrote:

> When you want to have people adopt Standards, it is essential that
> there is no discrepancy between these two bodies of work. It is a
> marketing disaster for the Standard when you have to use a
> rationalisation like "Ethnologue is not the standard, the standard is
> http://www.sil.org/iso639-3/ here".

Ethnologue is not the standard.  In preparing RFC 4645bis to use subtags
based on ISO 639-3 code elements, I am planning to use the official ISO
639-3 data, not the data that was used as initial input to ISO 639-3.

Talk to Peter about marketing ISO 639-3.  I'm concerned with getting the
data into the Registry properly.

> It is a well known fact that the ISO-639-3 is based on Ethnologue and
> that SIL is the registrar. It is reasonable to expect that these is a
> good relation between the two. Using the "|" is not the character that
> should be used in the first place.

Why do you suppose the vertical bars were changed to forward slashes?
Possibly to avoid the problem with vertical bars that you complained
about in the first place?

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


------=_Part_5884_20006791.1172565411428-- --===============0763505702== 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 --===============0763505702==-- From ltru-bounces@ietf.org Tue Feb 27 04:47:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLyv2-0005Xw-Kd; Tue, 27 Feb 2007 04:46:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLyv2-0005Xr-2a for ltru@ietf.org; Tue, 27 Feb 2007 04:46:48 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLyuz-0001TZ-3l for ltru@ietf.org; Tue, 27 Feb 2007 04:46:48 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l1R9kfOH026793 for ; Tue, 27 Feb 2007 18:46:41 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 0261_6d549716_c647_11db_90d1_0014221f2a2d; Tue, 27 Feb 2007 18:46:41 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:57535) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 27 Feb 2007 18:45:42 +0900 Message-Id: <6.0.0.20.2.20070227183715.09328790@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 27 Feb 2007 18:44:45 +0900 To: "Gerard Meijssen" , "Doug Ewell" From: Martin Duerst Subject: Re: [Ltru] Re: "Placeholder" dates in draft Registry In-Reply-To: <41a006820702270036y54918b6cw6d65f406b4f2d60@mail.gmail.com > References: <001901c75a16$ac85f8f0$6401a8c0@DGBP7M81> <45E3DD61.7010406@gmail.com> <002501c75a43$634e6820$6401a8c0@DGBP7M81> <41a006820702262357o3d2ef494s9b5e2ad7cd91b9a@mail.gmail.com> <003001c75a46$d0d85ec0$6401a8c0@DGBP7M81> <41a006820702270036y54918b6cw6d65f406b4f2d60@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: 92df29fa99cf13e554b84c8374345c17 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Gerard, I agree that it would be great if Ethnologue and ISO-639-3 were in perfect sync. And I hope both parties will work on this. However, as the LTRU WG, we are a third party. Each of the participants in the LTRU WG can tell the people responsible for the Ethnologue and for ISO 639-3 to work better to be in sync. And I'm sure they will listen, although it may take time. If you want to propose that we take the data from Ethnologue instead of ISO-639-3, you can do so, but I guess it may be difficult to conivince the group, not the least because the latter is mentioned in our charter, but the former isn't (see http://www.ietf.org/html.charters/ltru-charter.html). Anyway, once they are again in sync, it won't matter anymore :-). Regards, Martin. At 17:36 07/02/27, Gerard Meijssen wrote: >Hoi, >When each and every one of us do not take the marketing of this work serious, the standard will not be taken more serious than it is. With only 15% of the content of the Internet tagged at all and most of that tagged incorrectly we are not doing a good job. By looking at these numbers I can not come to a different conclusion. > >When you say that you are busy getting the data in the registry properly, you in effect assume that the registry will reflect the standard. The expectation raised is as reliable as mine that Ethnologue and ISO-639-3 are in sync. I do appreciate and expect that you will do a good job. > >There are huge benefits possible when content is tagged correctly. At this moment we do not reach the tipping point where this is true. There is this open source project called Shtooka, they record pronunciations in the flacc format; these sound files allow for the integration of the meta-data. What would be easier than having it tagged with the correct codes based on the language indicated by the speaker ... It was not even considered. We just do not have the necessary traction. The standard just does not have enough relevance. This is partly because "the marketing is for others to do" while it will really work best if we all give it some priority and make it a part of what we do. > >Thanks, > Gerard > >On 2/27/07, Doug Ewell <dewell@adelphia.net> wrote: >>GerardM wrote: >> >>> When you want to have people adopt Standards, it is essential that >>> there is no discrepancy between these two bodies of work. It is a >>> marketing disaster for the Standard when you have to use a >>> rationalisation like "Ethnologue is not the standard, the standard is >>> http://www.sil.org/iso639-3/ here". >> >>Ethnologue is not the standard. In preparing RFC 4645bis to use subtags >>based on ISO 639-3 code elements, I am planning to use the official ISO >>639-3 data, not the data that was used as initial input to ISO 639-3. >> >>Talk to Peter about marketing ISO 639-3. I'm concerned with getting the >>data into the Registry properly. >> >>> It is a well known fact that the ISO-639-3 is based on Ethnologue and >>> that SIL is the registrar. It is reasonable to expect that these is a >>> good relation between the two. Using the "|" is not the character that >>> should be used in the first place. >> >>Why do you suppose the vertical bars were changed to forward slashes? >>Possibly to avoid the problem with vertical bars that you complained >>about in the first place? >> >>-- >>Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 >>http://users.adelphia.net/~dewell/ >>http://www1.ietf.org/html.charters/ltru-charter.html >>http://www.alvestrand.no/mailman/listinfo/ietf-languages > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 27 05:29:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzZm-0000wq-UT; Tue, 27 Feb 2007 05:28:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzZl-0000wg-Kv for ltru@ietf.org; Tue, 27 Feb 2007 05:28:53 -0500 Received: from wr-out-0506.google.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLzZh-0006fP-VQ for ltru@ietf.org; Tue, 27 Feb 2007 05:28:53 -0500 Received: by wr-out-0506.google.com with SMTP id 58so1965226wri for ; Tue, 27 Feb 2007 02:28:49 -0800 (PST) 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=HkTD3VUzXoJmW8zpCgpJZ08S3Sw91gpgmMgfEOUpeRSnLQ0hCjQaAFWRcSO29x+T1FYvnbDYcFZoGdhWd0VqQyqWRyxF4rdopcG7LvVlhgCdRR2vVY4M3fUMadIuRLSEaxEtKelW5ZOD5i+lvyEDTWZe20RnlSVuRoG8h8y5R2w= 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=Vj7TVIdgDNKa/R0pZiLeA7AESKj3yD5fL5cD6/tkqwIJJzKs9UCPPIey5Px0Upk5oSYtaAttoHsGvL1FY6+iHy+mxUtLOp7165rNnU48buJIch+ym8xwGV4SMvQtlRXrGrCq4Q8zqKnxGvu8Q8ZgauD8F7Rv6syqNY5UYoR7qtk= Received: by 10.114.193.1 with SMTP id q1mr2478486waf.1172572125518; Tue, 27 Feb 2007 02:28:45 -0800 (PST) Received: by 10.114.161.8 with HTTP; Tue, 27 Feb 2007 02:28:45 -0800 (PST) Message-ID: <41a006820702270228o7974fdc5p5ef2e649ee7d76cd@mail.gmail.com> Date: Tue, 27 Feb 2007 11:28:45 +0100 From: "Gerard Meijssen" To: "Martin Duerst" Subject: Re: [Ltru] Re: "Placeholder" dates in draft Registry In-Reply-To: <6.0.0.20.2.20070227183715.09328790@localhost> MIME-Version: 1.0 References: <001901c75a16$ac85f8f0$6401a8c0@DGBP7M81> <45E3DD61.7010406@gmail.com> <002501c75a43$634e6820$6401a8c0@DGBP7M81> <41a006820702262357o3d2ef494s9b5e2ad7cd91b9a@mail.gmail.com> <003001c75a46$d0d85ec0$6401a8c0@DGBP7M81> <41a006820702270036y54918b6cw6d65f406b4f2d60@mail.gmail.com> <6.0.0.20.2.20070227183715.09328790@localhost> X-Google-Sender-Auth: 8b93d17e265b7230 X-Spam-Score: 0.5 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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="===============0709375746==" Errors-To: ltru-bounces@ietf.org --===============0709375746== Content-Type: multipart/alternative; boundary="----=_Part_7824_5041400.1172572125453" ------=_Part_7824_5041400.1172572125453 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi, You are perfectly right. From the outside, it however makes not much of a difference. The perception is that Standards are a mess, they are secretive, expensive, academic and hardly relevant. This is completely contrary to what we want; in order for Standards to be relevant they have to be seen, accepted and adopted as the Standard. To do this we have to make sure that people know about all the Standards that are important to us. We have to market these Standards. Marketing is what is needed. In my opinion one of the best places to start is to get software applications to adopt the Standards. This means content creation programs, browsers, you name them. By having people select the linguistic entity they use, you can have the content automatically tagged with the corresponding label. I do not propose to make Ethnologue leading. That would be silly. Given that the LTRU follows the work done in the ISO-639-3, we cannot tell the people behind it to do a better job. What they do is leading, consequently they do the best job. Thanks, GerardM On 2/27/07, Martin Duerst wrote: > > Hello Gerard, > > I agree that it would be great if Ethnologue and ISO-639-3 were > in perfect sync. And I hope both parties will work on this. > > However, as the LTRU WG, we are a third party. Each of the > participants in the LTRU WG can tell the people responsible > for the Ethnologue and for ISO 639-3 to work better to be in > sync. And I'm sure they will listen, although it may take time. > > If you want to propose that we take the data from Ethnologue > instead of ISO-639-3, you can do so, but I guess it may be > difficult to conivince the group, not the least because > the latter is mentioned in our charter, but the former isn't > (see http://www.ietf.org/html.charters/ltru-charter.html). > Anyway, once they are again in sync, it won't matter anymore :-). > > Regards, Martin. > > > At 17:36 07/02/27, Gerard Meijssen wrote: > >Hoi, > >When each and every one of us do not take the marketing of this work > serious, the standard will not be taken more serious than it is. With only > 15% of the content of the Internet tagged at all and most of that tagged > incorrectly we are not doing a good job. By looking at these numbers I can > not come to a different conclusion. > > > >When you say that you are busy getting the data in the registry properly, > you in effect assume that the registry will reflect the standard. The > expectation raised is as reliable as mine that Ethnologue and ISO-639-3 are > in sync. I do appreciate and expect that you will do a good job. > > > >There are huge benefits possible when content is tagged correctly. At > this moment we do not reach the tipping point where this is true. There is > this open source project called Shtooka, they record pronunciations in the > flacc format; these sound files allow for the integration of the meta-data. > What would be easier than having it tagged with the correct codes based on > the language indicated by the speaker ... It was not even considered. We > just do not have the necessary traction. The standard just does not have > enough relevance. This is partly because "the marketing is for others to do" > while it will really work best if we all give it some priority and make it a > part of what we do. > > > >Thanks, > > Gerard > > > >On 2/27/07, Doug Ewell <dewell@adelphia.net> > wrote: > >>GerardM wrote: > >> > >>> When you want to have people adopt Standards, it is essential that > >>> there is no discrepancy between these two bodies of work. It is a > >>> marketing disaster for the Standard when you have to use a > >>> rationalisation like "Ethnologue is not the standard, the standard is > >>> http://www.sil.org/iso639-3/ here". > >> > >>Ethnologue is not the standard. In preparing RFC 4645bis to use subtags > >>based on ISO 639-3 code elements, I am planning to use the official ISO > >>639-3 data, not the data that was used as initial input to ISO 639-3. > >> > >>Talk to Peter about marketing ISO 639-3. I'm concerned with getting the > >>data into the Registry properly. > >> > >>> It is a well known fact that the ISO-639-3 is based on Ethnologue and > >>> that SIL is the registrar. It is reasonable to expect that these is a > >>> good relation between the two. Using the "|" is not the character that > >>> should be used in the first place. > >> > >>Why do you suppose the vertical bars were changed to forward slashes? > >>Possibly to avoid the problem with vertical bars that you complained > >>about in the first place? > >> > >>-- > >>Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > >>http://users.adelphia.net/~dewell/ > >>http://www1.ietf.org/html.charters/ltru-charter.html > >> > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > >_______________________________________________ > >Ltru mailing list > >Ltru@ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > ------=_Part_7824_5041400.1172572125453 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hoi,
You are perfectly right. From the outside, it however makes not much of a  difference. The perception is that Standards are a mess, they are secretive, expensive, academic and hardly relevant. This is completely contrary to what we want; in order for Standards to be relevant they have to be seen, accepted and adopted as the Standard. To do this we have to make sure that people know about all the Standards that are important to us. We have to market these Standards.

Marketing is what is needed. In my opinion one of the best places to start is to get software applications to adopt the Standards. This means content creation programs, browsers, you name them. By having people select the linguistic entity they use, you can have the content automatically tagged with the corresponding label.

I do not propose to make Ethnologue leading. That would be silly. Given that the LTRU follows the work done in the ISO-639-3, we cannot tell the people behind it to do a better job. What they do is leading, consequently they do the best job.

Thanks,
    GerardM


On 2/27/07, Martin Duerst <duerst@it.aoyama.ac.jp> wrote:
Hello Gerard,

I agree that it would be great if Ethnologue and ISO-639-3 were
in perfect sync. And I hope both parties will work on this.

However, as the LTRU WG, we are a third party. Each of the
participants in the LTRU WG can tell the people responsible
for the Ethnologue and for ISO 639-3 to work better to be in
sync. And I'm sure they will listen, although it may take time.

If you want to propose that we take the data from Ethnologue
instead of ISO-639-3, you can do so, but I guess it may be
difficult to conivince the group, not the least because
the latter is mentioned in our charter, but the former isn't
(see http://www.ietf.org/html.charters/ltru-charter.html ).
Anyway, once they are again in sync, it won't matter anymore :-).

Regards,    Martin.


At 17:36 07/02/27, Gerard Meijssen wrote:
>Hoi,
>When each and every one of us do not take the marketing of this work serious, the standard will not be taken more serious than it is. With only 15% of the content of the Internet tagged at all and most of that tagged incorrectly we are not doing a good job. By looking at these numbers I can not come to a different conclusion.
>
>When you say that you are busy getting the data in the registry properly, you in effect assume that the registry will reflect the standard. The expectation raised is as reliable as mine that Ethnologue and ISO-639-3 are in sync. I do appreciate and expect that you will do a good job.
>
>There are huge benefits possible when content is tagged correctly. At this moment we do not reach the tipping point where this is true. There is this open source project called Shtooka, they record pronunciations in the flacc format; these sound files allow for the integration of the meta-data. What would be easier than having it tagged with the correct codes based on the language indicated by the speaker ... It was not even considered. We just do not have the necessary traction. The standard just does not have enough relevance. This is partly because "the marketing is for others to do" while it will really work best if we all give it some priority and make it a part of what we do.
>
>Thanks,
>    Gerard
>
>On 2/27/07, Doug Ewell <<mailto:dewell@adelphia.net>dewell@adelphia.net> wrote:
>>GerardM wrote:
>>
>>> When you want to have people adopt Standards, it is essential that
>>> there is no discrepancy between these two bodies of work. It is a
>>> marketing disaster for the Standard when you have to use a
>>> rationalisation like "Ethnologue is not the standard, the standard is
>>> <http://www.sil.org/iso639-3/> http://www.sil.org/iso639-3/ here".
>>
>>Ethnologue is not the standard.  In preparing RFC 4645bis to use subtags
>>based on ISO 639-3 code elements, I am planning to use the official ISO
>>639-3 data, not the data that was used as initial input to ISO 639-3.
>>
>>Talk to Peter about marketing ISO 639-3.  I'm concerned with getting the
>>data into the Registry properly.
>>
>>> It is a well known fact that the ISO-639-3 is based on Ethnologue and
>>> that SIL is the registrar. It is reasonable to expect that these is a
>>> good relation between the two. Using the "|" is not the character that
>>> should be used in the first place.
>>
>>Why do you suppose the vertical bars were changed to forward slashes?
>>Possibly to avoid the problem with vertical bars that you complained
>>about in the first place?
>>
>>--
>>Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
>><http://users.adelphia.net/~dewell/ >http://users.adelphia.net/~dewell/
>>http://www1.ietf.org/html.charters/ltru-charter.html
>><http://www.alvestrand.no/mailman/listinfo/ietf-languages>http://www.alvestrand.no/mailman/listinfo/ietf-languages
>
>_______________________________________________
>Ltru mailing list
>Ltru@ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


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


------=_Part_7824_5041400.1172572125453-- --===============0709375746== 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 --===============0709375746==-- From ltru-bounces@ietf.org Tue Feb 27 05:47:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzrA-0001KP-Hk; Tue, 27 Feb 2007 05:46:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzr8-0001Im-Og for ltru@ietf.org; Tue, 27 Feb 2007 05:46:50 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLzr3-000120-FM for ltru@ietf.org; Tue, 27 Feb 2007 05:46:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id EAF1626C228; Tue, 27 Feb 2007 11:46:25 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 37BC826C21F; Tue, 27 Feb 2007 11:46:23 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 344E558ED19; Tue, 27 Feb 2007 11:46:23 +0100 (CET) Date: Tue, 27 Feb 2007 11:46:23 +0100 From: Stephane Bortzmeyer To: Gerard Meijssen Message-ID: <20070227104623.GA24980@nic.fr> References: <001901c75a16$ac85f8f0$6401a8c0@DGBP7M81> <45E3DD61.7010406@gmail.com> <002501c75a43$634e6820$6401a8c0@DGBP7M81> <41a006820702262357o3d2ef494s9b5e2ad7cd91b9a@mail.gmail.com> <003001c75a46$d0d85ec0$6401a8c0@DGBP7M81> <41a006820702270036y54918b6cw6d65f406b4f2d60@mail.gmail.com> <6.0.0.20.2.20070227183715.09328790@localhost> <41a006820702270228o7974fdc5p5ef2e649ee7d76cd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41a006820702270228o7974fdc5p5ef2e649ee7d76cd@mail.gmail.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: LTRU Working Group Subject: [Ltru] Marketing of the standard (Was: "Placeholder" dates in draft Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Feb 27, 2007 at 11:28:45AM +0100, Gerard Meijssen wrote a message of 173 lines which said: > In my opinion one of the best places to start is to get software > applications to adopt the Standards. Do not forget also the other Standards, often better known than RFC 4646. Many of them just reference "ISO 639" without any knowledge of the complications involved. PS: do not forget the http://ltru.generic-nic.net/ project. Tell me if it is on the right track and if it should be promoted louder. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 27 09:56:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3kE-0001ZP-Tf; Tue, 27 Feb 2007 09:55:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3kE-0001Yv-9B for ltru@ietf.org; Tue, 27 Feb 2007 09:55:58 -0500 Received: from mta20.mail.adelphia.net ([68.168.78.254] helo=mta1.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM3kC-0008NC-UI for ltru@ietf.org; Tue, 27 Feb 2007 09:55:58 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070227145003.WWBP27841.mta11.adelphia.net@DGBP7M81>; Tue, 27 Feb 2007 09:50:03 -0500 Message-ID: <004a01c75a7e$9043cc90$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <001901c75a16$ac85f8f0$6401a8c0@DGBP7M81> <45E3DD61.7010406@gmail.com> <002501c75a43$634e6820$6401a8c0@DGBP7M81> <41a006820702262357o3d2ef494s9b5e2ad7cd91b9a@mail.gmail.com> <003001c75a46$d0d85ec0$6401a8c0@DGBP7M81> <41a006820702270036y54918b6cw6d65f406b4f2d60@mail.gmail.com> Date: Tue, 27 Feb 2007 06:50:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Gerard Meijssen Subject: [Ltru] Re: "Placeholder" dates in draft Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Gerard Meijssen wrote: > When each and every one of us do not take the marketing of this work > serious, the standard will not be taken more serious than it is. I am a technical professional and prefer to leave the important work of marketing to people who are professionals in that field. > With only 15% of the content of the Internet tagged at all and most of > that tagged incorrectly we are not doing a good job. By looking at > these numbers I can not come to a different conclusion. I really don't want to debate this premise that the success of our technical work is dependent on how well we market it to vendors, least of all on whether every last MySpace page is tagged correctly. Eighty-five percent of the Internet includes a lot of rubbish. If the "serious" 15% is tagged properly, that will be a win. > When you say that you are busy getting the data in the registry > properly, you in effect assume that the registry will reflect the > standard. Of course. The Registry is part of the standard by definition. > The expectation raised is as reliable as mine that Ethnologue and > ISO-639-3 are in sync. Not analogous. ISO 639-3/RA does not claim that the ISO standard matches Ethnologue exactly, including non-normative language names. Indeed, Ethnologue is not the only source of data for ISO 639-3, there is a significant body of code elements for extinct, ancient, historic, and constructed languages that are taken from Linguist List. > The perception is that Standards are a mess, they are secretive, > expensive, academic and hardly relevant. This is completely contrary > to what we want; in order for Standards to be relevant they have to be > seen, accepted and adopted as the Standard. To do this we have to make > sure that people know about all the Standards that are important to > us. We have to market these Standards. If you would like to take on the job of evangelizing this standard (lowercase 's') to users and vendors, I support you fully. You are probably better qualified for this job than I am. Meanwhile I will work to make sure the work you are evangelizing is not garbage. If the work is garbage, it really doesn't matter how good the marketing is. > Marketing is what is needed. In my opinion one of the best places to > start is to get software applications to adopt the Standards. This > means content creation programs, browsers, you name them. By having > people select the linguistic entity they use, you can have the content > automatically tagged with the corresponding label. I certainly agree that software that creates or requests content should support language tagging as defined by RFC 4646 and 4647, and eventually 4646bis. Please let us get back to the remaining open issues on our list. It is now January 58 and if we don't pick up the pace we may miss the January deadlines in our charter. -- 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 Feb 27 10:31:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4II-0003uB-Cf; Tue, 27 Feb 2007 10:31:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4IH-0003u5-LO for ltru@ietf.org; Tue, 27 Feb 2007 10:31:09 -0500 Received: from mail11.svc.cra.dublin.eircom.net ([159.134.118.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HM4IF-000314-6D for ltru@ietf.org; Tue, 27 Feb 2007 10:31:09 -0500 Received: (qmail 38619 messnum 11077173 invoked from network[194.125.174.72/ts09-072.dublin.indigo.ie]); 27 Feb 2007 15:31:05 -0000 Received: from ts09-072.dublin.indigo.ie (HELO ?194.125.174.72?) (194.125.174.72) by mail11.svc.cra.dublin.eircom.net (qp 38619) with SMTP; 27 Feb 2007 15:31:05 -0000 In-Reply-To: <004a01c75a7e$9043cc90$6401a8c0@DGBP7M81> References: <001901c75a16$ac85f8f0$6401a8c0@DGBP7M81> <45E3DD61.7010406@gmail.com> <002501c75a43$634e6820$6401a8c0@DGBP7M81> <41a006820702262357o3d2ef494s9b5e2ad7cd91b9a@mail.gmail.com> <003001c75a46$d0d85ec0$6401a8c0@DGBP7M81> <41a006820702270036y54918b6cw6d65f406b4f2d60@mail.gmail.com> <004a01c75a7e$9043cc90$6401a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <93D7B3CD-DAEB-4EF2-98A1-1B60E4293F2C@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: "Placeholder" dates in draft Registry Date: Tue, 27 Feb 2007 15:33:28 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 27 Feb 2007, at 14:50, scr=EDobh Doug Ewell: > ... If the work is garbage, it really doesn't matter how good the =20 > marketing is... True, all things being equal (which I wish they were). > Please let us get back to the remaining open issues on our list. =20 > It is now January 58 and if we don't pick up the pace we may miss =20 > the January deadlines in our charter. Ref. "January 58" makes no sense at all. Is it a typo? mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 27 10:37:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4OE-0002Pt-8f; Tue, 27 Feb 2007 10:37:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4OC-0002Ob-B1 for ltru@ietf.org; Tue, 27 Feb 2007 10:37:16 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4OB-0003zs-2q for ltru@ietf.org; Tue, 27 Feb 2007 10:37:16 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 91CF326C2C7; Tue, 27 Feb 2007 16:36:57 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 072EA26C2A9; Tue, 27 Feb 2007 16:36:57 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id ED56358ED19; Tue, 27 Feb 2007 16:36:56 +0100 (CET) Date: Tue, 27 Feb 2007 16:36:56 +0100 From: Stephane Bortzmeyer To: Marion Gunn Message-ID: <20070227153656.GA30864@nic.fr> References: <001901c75a16$ac85f8f0$6401a8c0@DGBP7M81> <45E3DD61.7010406@gmail.com> <002501c75a43$634e6820$6401a8c0@DGBP7M81> <41a006820702262357o3d2ef494s9b5e2ad7cd91b9a@mail.gmail.com> <003001c75a46$d0d85ec0$6401a8c0@DGBP7M81> <41a006820702270036y54918b6cw6d65f406b4f2d60@mail.gmail.com> <004a01c75a7e$9043cc90$6401a8c0@DGBP7M81> <93D7B3CD-DAEB-4EF2-98A1-1B60E4293F2C@egt.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93D7B3CD-DAEB-4EF2-98A1-1B60E4293F2C@egt.ie> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: LTRU Working Group Subject: [Ltru] Re: "Placeholder" dates in draft Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Feb 27, 2007 at 03:33:28PM +0000, Marion Gunn wrote a message of 25 lines which said: > >Please let us get back to the remaining open issues on our list. > >It is now January 58 and if we don't pick up the pace we may miss > >the January deadlines in our charter. > > Ref. "January 58" makes no sense at all. Is it a typo? No. A cute joke. January 58 == February 27 (58 - 31), aka today. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 27 10:59:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4jA-00088G-TM; Tue, 27 Feb 2007 10:58:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4j9-000889-At for ltru@ietf.org; Tue, 27 Feb 2007 10:58:55 -0500 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4j8-0006ic-4P for ltru@ietf.org; Tue, 27 Feb 2007 10:58:55 -0500 Received: by wx-out-0506.google.com with SMTP id h31so1805924wxd for ; Tue, 27 Feb 2007 07:58:53 -0800 (PST) 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=QgEqiK1TLTynPomdgKXQmUA0Dz/RoHVF4Jj9XiYlRtrN9QBN2e5eLSb1FGp0xbZ7reH8lHkzzCtwMr2Gjr4xYWdNIA4JX8dVV/NWVmLf7zQ1s+sXqRpNReJV0rno56Egw99FR+rFSBqnnTFhzc2D9sXq4Uo6Vo7SozLVfhtS5z8= 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=qs9J4GRbaQuz81DQqz/uvmj6AjECj0FwPHhrb+W2pQbOxaJzbCU4sftHKQ0ZD49nd3mHyVuq9DR2iP0tjVOjP0YY6gP7b28wPXzvBOv5Y7cKqBQOu8kMYWT6OS3JhLNwu8BWmCmXzusmFaPehy+tNvhbGm9sXgv2hpM32ebZygk= Received: by 10.90.72.10 with SMTP id u10mr6318859aga.1172591933893; Tue, 27 Feb 2007 07:58:53 -0800 (PST) Received: by 10.90.50.16 with HTTP; Tue, 27 Feb 2007 07:58:53 -0800 (PST) Message-ID: <30b660a20702270758y544a42bcl9d78f0806df8d05c@mail.gmail.com> Date: Tue, 27 Feb 2007 07:58:53 -0800 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: 99af0b8bdf30fb3b X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Proposals for changes to latest draft X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0149071238==" Errors-To: ltru-bounces@ietf.org --===============0149071238== Content-Type: multipart/alternative; boundary="----=_Part_89623_6820306.1172591933842" ------=_Part_89623_6820306.1172591933842 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I have a number of proposals for changes to the current draft. So that we have specific wording to discuss, I posted a modified draft on the web at http://docs.google.com/Doc?id=dfqr8rd5_4gh864p The deletions are marked with strikeout, and the additions with yellow. (The formatting is somewhat disturbed in using this mechanism, so ignore any other formatting differences from the latest HTML draft on Addison's site). Mark ------=_Part_89623_6820306.1172591933842 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I have a number of proposals for changes to the current draft. So that we have specific wording to discuss, I posted a modified draft on the web at

http://docs.google.com/Doc?id=dfqr8rd5_4gh864p

The deletions are marked with strikeout, and the additions with yellow. (The formatting is somewhat disturbed in using this mechanism, so ignore any other formatting differences from the latest HTML draft on Addison's site).

Mark
------=_Part_89623_6820306.1172591933842-- --===============0149071238== 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 --===============0149071238==-- From ltru-bounces@ietf.org Tue Feb 27 11:11:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4vS-0003H1-Nw; Tue, 27 Feb 2007 11:11:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4vR-0003Fj-2g for ltru@ietf.org; Tue, 27 Feb 2007 11:11:37 -0500 Received: from smtp5.pp.htv.fi ([213.243.153.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4vK-0000Ai-VS for ltru@ietf.org; Tue, 27 Feb 2007 11:11:37 -0500 Received: from Raahattava (cs181252091.pp.htv.fi [82.181.252.91]) by smtp5.pp.htv.fi (Postfix) with ESMTP id D2EA55BC05C; Tue, 27 Feb 2007 18:10:56 +0200 (EET) From: "Erkki I. Kolehmainen" To: "'Marion Gunn'" , "'LTRU Working Group'" Subject: VS: [Ltru] Re: "Placeholder" dates in draft Registry Date: Tue, 27 Feb 2007 18:10:56 +0200 Message-ID: <000a01c75a89$dcbfb880$0200a8c0@Raahattava> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <93D7B3CD-DAEB-4EF2-98A1-1B60E4293F2C@egt.ie> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Marion, it makes sense to me. February 27th is the 58th day since the beginning = of January, and since the deadline is the end of January, for us, January = still continues. Erkki Erkki I. Kolehmainen Tilkankatu 12 A 3, FI-00300 Helsinki, Finland Puh. (09) 4368 2643, 0400 825 943; Tel. +358 9 4368 2643, +358 400 825 = 943 =20 -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Marion Gunn [mailto:mgunn@egt.ie]=20 L=E4hetetty: 27. helmikuuta 2007 17:33 Vastaanottaja: LTRU Working Group Aihe: Re: [Ltru] Re: "Placeholder" dates in draft Registry On 27 Feb 2007, at 14:50, scr=EDobh Doug Ewell: > ... If the work is garbage, it really doesn't matter how good the > marketing is... True, all things being equal (which I wish they were). > Please let us get back to the remaining open issues on our list. =20 > It is now January 58 and if we don't pick up the pace we may miss > the January deadlines in our charter. Ref. "January 58" makes no sense at all. Is it a typo? mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 27 14:51:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM8Lh-0001Bz-Gf; Tue, 27 Feb 2007 14:50:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM8Lh-0001Bg-3f for ltru@ietf.org; Tue, 27 Feb 2007 14:50:57 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM8Le-0008Jl-K4 for ltru@ietf.org; Tue, 27 Feb 2007 14:50:57 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HM8Ld-0000AT-8I; Tue, 27 Feb 2007 14:50:53 -0500 Date: Tue, 27 Feb 2007 14:50:53 -0500 To: Mark Davis Subject: Re: [Ltru] Proposals for changes to latest draft Message-ID: <20070227195053.GB1965@mercury.ccil.org> References: <30b660a20702270758y544a42bcl9d78f0806df8d05c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20702270758y544a42bcl9d78f0806df8d05c@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 scripsit: > The deletions are marked with strikeout, and the additions with yellow. > (The formatting is somewhat disturbed in using this mechanism, so > ignore any other formatting differences from the latest HTML draft on > Addison's site). Here's my take: 2.2.3 bullet 6 adds the notion that the hitherto private tag Qabx is to be usurped to mean "no written content". I agree that the "unwritten languages" script tag does not do the job here, but I deny that it is proper to steal a private-use tag, and I don't see any need to have such an entity at all. 2.2.9: I'm happy to add the notion of well-formed and valid tags officially, since we use them informally. I'm also happy with the idea that repeated variant subtags are inherently invalid. However, the change to the interpretation of variant prefixes does not seem to deal correctly with the case of a variant subtag with more than one Prefix: field. 3.1.2 has new language to prevent recursive variant subtags: thus if avariant has a prefix of xx-bvariant, bvariant cannot have a prefix of xx-avariant. +1 3.1.4: specifies some types of irregularities in descriptions that may be fixed. Motherhood. +1 3.2 is heavily recast with lots of "constitutional" baggage around the LSR: two-year term, alternate appointed, MUST reflect the consensus of informed opinion on the list (whose opinions are considered to be informed?) All of this is entirely unnecessary to say the least. All we need is a statement affirming the right of the LSR to delegate his duties while remaining responsible for them. 3.3 now has the LSR sending whole new registries to IANA on each change. This is a very error-prone procedure, as entries could be added or dropped in error. The current procedure of instructing IANA which entries to add or change (there are no drops) is now working well and should be left alone. Whole new registries are relevant when we add bulk changes at the time of a new RFC. 3.5 has an editorial change. +1. 4.1 adds another version of the stricture against -variant1-variant1 tags. +1 4.4 adds a new rule for canonicalizing tags with multiple variant subtags, thus: Any sequence of variant tags MUST be reordered such that for each variant subtags A and B, A comes before B if 1. A has no prefix and B has a prefix 2. or A and B are not ordered by #1, and A is part of a prefix (given the previous non-variant subtags) for B 3. or A and B are not ordered by #1 or #2, and A is alphabetically before B I'm good with this. 5.1 has more language about sending whole registries. -1 as noted above. -- John Cowan http://ccil.org/~cowan cowan@ccil.org Economists were put on this planet to make astrologers look good. --Leo McGarry _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 27 15:21:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM8op-00055p-9E; Tue, 27 Feb 2007 15:21:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM8on-000546-Qx for ltru@ietf.org; Tue, 27 Feb 2007 15:21:01 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM8om-0003A3-D1 for ltru@ietf.org; Tue, 27 Feb 2007 15:21:01 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l1RKKKhh038208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Feb 2007 12:20:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=0+BzRMsX2Ik1VjBa439iz/I9oLtnHQKvViwmTXkFrhYQQ9uyL/y6PiCEe/TsDyur Message-ID: <45E49284.4060107@yahoo-inc.com> Date: Tue, 27 Feb 2007 12:20:20 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Proposals for changes to latest draft References: <30b660a20702270758y544a42bcl9d78f0806df8d05c@mail.gmail.com> <20070227195053.GB1965@mercury.ccil.org> In-Reply-To: <20070227195053.GB1965@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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 Comments follow on John's comments. Addison John Cowan wrote: > Mark Davis scripsit: > >> The deletions are marked with strikeout, and the additions with yellow. >> (The formatting is somewhat disturbed in using this mechanism, so >> ignore any other formatting differences from the latest HTML draft on >> Addison's site). > > Here's my take: > > 2.2.3 bullet 6 adds the notion that the hitherto private tag Qabx is to > be usurped to mean "no written content". I agree that the "unwritten > languages" script tag does not do the job here, but I deny that it is > proper to steal a private-use tag, and I don't see any need to have such > an entity at all. +1. Further, I'm not sure why one would tag content as "not written". Not including a script subtag does an admirable job of indicating the language in these cases. > > 2.2.9: I'm happy to add the notion of well-formed and valid tags > officially, since we use them informally. I'm also happy with the idea > that repeated variant subtags are inherently invalid. I'm not sure I'm happy changing from measuring implementations to measuring tags. My problem is that it is more useful in practice to talk about the capabilities of a particular implementation. > However, the change > to the interpretation of variant prefixes does not seem to deal correctly > with the case of a variant subtag with more than one Prefix: field. The text on variant prefixes needs some minor massaging before inclusion, I think. > > 3.1.2 has new language to prevent recursive variant subtags: thus if > avariant has a prefix of xx-bvariant, bvariant cannot have a prefix > of xx-avariant. +1 +1, although it seems a bit pedantic. > > 3.1.4: specifies some types of irregularities in descriptions that may > be fixed. Motherhood. +1 +1 > > 3.2 is heavily recast with lots of "constitutional" baggage around the > LSR: two-year term, alternate appointed, MUST reflect the consensus > of informed opinion on the list (whose opinions are considered to > be informed?) All of this is entirely unnecessary to say the least. > All we need is a statement affirming the right of the LSR to delegate > his duties while remaining responsible for them. I agree that we need a statement on LSR delegation. I heavily agree with the change of SHOULD to MUST in Section 3.5 requiring the LSR to actually announce decisions after two weeks (grrr....), but some of this section's proposed text seems duplicative. I think a two-year term is prudent. I don't think we need to have an alternate. But the current, open-ended dictatorship is problematic to me. I think alternate wording is required to Mark's, though. Also, Mark renames the LSR incorrectly. I would suggest instead for the last paragraph: --- The Language Subtag Reviewer chairs the ietf-languages@iana.org discussion list. The reviewer MAY delegate any list or other administrative duties as necessary. As described in Section 3.5, the reviewer is solely responsible for determining consensus on a registration request and announcing the acceptance or rejection (or extension of discussion) of any particular request. The Language Subtag Reviewer is not permitted to delegate this responsibility. The decisions of the Language Subtag Reviewer MAY be appealed to the IESG under the same rules as other IETF decisions (see [RFC2026]). The IESG can reverse or overturn the decision of the Language Subtag Reviewer, provide guidance, or take other appropriate actions. --- > > 3.3 now has the LSR sending whole new registries to IANA on each change. > This is a very error-prone procedure, as entries could be added or dropped > in error. The current procedure of instructing IANA which entries to > add or change (there are no drops) is now working well and should be > left alone. Whole new registries are relevant when we add bulk changes > at the time of a new RFC. +1 for John's opposition to sending whole registries. > > 3.5 has an editorial change. +1. Actually, it's a substantive change to MUST, which I agree with. > > 4.1 adds another version of the stricture against -variant1-variant1 > tags. +1 +1 > > 4.4 adds a new rule for canonicalizing tags with multiple variant > subtags, thus: > > Any sequence of variant tags MUST be reordered such that for each variant subtags A and B, A comes before B if > > 1. A has no prefix and B has a prefix > 2. or A and B are not ordered by #1, and A is part of a prefix (given > the previous non-variant subtags) for B > 3. or A and B are not ordered by #1 or #2, and A is alphabetically > before B > > I'm good with this. I'm not. Canonicalization of this nature violates custom and practice in the formation of language tags. It has already been shown on the list that what one considers "wider" for a subtag another might consider "narrower". This requirement will break existing implementations for very little real-world improvement. I'm okay with providing some guidance on tag choice and subtag ordering, but not with more algorithm here. 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 Feb 27 15:49:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM9GD-0000bB-Ih; Tue, 27 Feb 2007 15:49:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM9GC-0000b0-D1 for ltru@ietf.org; Tue, 27 Feb 2007 15:49:20 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM9GA-0007pW-Qr for ltru@ietf.org; Tue, 27 Feb 2007 15:49:20 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HM9G5-0004SU-Ot; Tue, 27 Feb 2007 15:49:13 -0500 Date: Tue, 27 Feb 2007 15:49:13 -0500 To: Addison Phillips Subject: Re: [Ltru] Proposals for changes to latest draft Message-ID: <20070227204913.GE1965@mercury.ccil.org> References: <30b660a20702270758y544a42bcl9d78f0806df8d05c@mail.gmail.com> <20070227195053.GB1965@mercury.ccil.org> <45E49284.4060107@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45E49284.4060107@yahoo-inc.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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: > +1. Further, I'm not sure why one would tag content as "not written". > Not including a script subtag does an admirable job of indicating the > language in these cases. Omitting the script is technically ambiguous between "no script" and "may or may not have a script, which may or may not be known". What I would like to see proved is that this difference actually makes a difference in practice. Typically other kinds of metadata will differentiate textual from non-textual content. > I'm not sure I'm happy changing from measuring implementations to > measuring tags. My problem is that it is more useful in practice to talk > about the capabilities of a particular implementation. We talk about valid or invalid or not well-formed tags all the time. Consider your email http://www.alvestrand.no/pipermail/ietf-languages/2004-June/002034.html , which says "to know whether a tag is well-formed". > I heavily agree with the change of SHOULD to MUST in Section 3.5 > requiring the LSR to actually announce decisions after two weeks +1. I overlooked that. > (grrr....), but some of this section's proposed text seems duplicative. I could say more if I wished to. > I think a two-year term is prudent. I don't think we need to have an > alternate. But the current, open-ended dictatorship is problematic to > me. It is *not* a dictatorship. Michael can be removed by petition to the IESG. Furthermore, anyone who wishes to overturn a particular decision may institute an appeal. > The Language Subtag Reviewer chairs the ietf-languages@iana.org > discussion list. The reviewer MAY delegate any list or other > administrative duties as necessary. As described in Section 3.5, the > reviewer is solely responsible for determining consensus on a > registration request and announcing the acceptance or rejection (or > extension of discussion) of any particular request. The LSR is not a moderator, but a judge. He does not announce, but decides. We are his advisors. This is a revolutionary change. > I'm okay with providing some guidance on tag choice and subtag ordering, > but not with more algorithm here. "We'll argue that point," said Jack. --_Mr. Midshipman Easy_ -- A mosquito cried out in his pain, John Cowan "A chemist has poisoned my brain!" http://www.ccil.org/~cowan The cause of his sorrow cowan@ccil.org Was para-dichloro- Diphenyltrichloroethane. (aka DDT) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 27 17:37:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAKj-0004l7-5I; Tue, 27 Feb 2007 16:58:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAKi-0004kO-Bz for ltru@ietf.org; Tue, 27 Feb 2007 16:58:04 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMAAE-0008Ut-IN for ltru@ietf.org; Tue, 27 Feb 2007 16:47:18 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l1RLkpJT044675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Feb 2007 13:46:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=HY5buOekoQbDl+jC0IyYgA/ztt8q7IRsnXUBmMAN9HDIm5KXNWOJArsIEFzbdyQ4 Message-ID: <45E4A6CB.4080005@yahoo-inc.com> Date: Tue, 27 Feb 2007 13:46:51 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Proposals for changes to latest draft References: <30b660a20702270758y544a42bcl9d78f0806df8d05c@mail.gmail.com> <20070227195053.GB1965@mercury.ccil.org> <45E49284.4060107@yahoo-inc.com> <20070227204913.GE1965@mercury.ccil.org> In-Reply-To: <20070227204913.GE1965@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp2.corp.yahoo.com id l1RLkpJT044675 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 responded: >=20 >> +1. Further, I'm not sure why one would tag content as "not written".=20 >> Not including a script subtag does an admirable job of indicating the=20 >> language in these cases. >=20 > Omitting the script is technically ambiguous between "no script" and > "may or may not have a script, which may or may not be known". What > I would like to see proved is that this difference actually makes a > difference in practice. Typically other kinds of metadata will > differentiate textual from non-textual content. Yes, it is technically ambiguous, but there doesn't seem to me to be a=20 use case in which it matters. >=20 >> I'm not sure I'm happy changing from measuring implementations to=20 >> measuring tags. My problem is that it is more useful in practice to ta= lk=20 >> about the capabilities of a particular implementation. >=20 > We talk about valid or invalid or not well-formed tags all the time. > Consider your email http://www.alvestrand.no/pipermail/ietf-languages/2= 004-June/002034.html , > which says "to know whether a tag is well-formed". Yes, yes, all very well. But this section of the document is about=20 conformance requirements. Conformance of what? It really shouldn't be=20 tags, since they are, ultimately, just strings that are being tested=20 somehow. What matters is whether an implementation checks if a given=20 string is well-formed, valid, or something else. I agree that this section will read better if we use Mark's definitions=20 based on tag conformance (allowing emails such as mine to pass muster).=20 But the section should then proceed to talk about applying the terms to=20 implementations. It makes no sense to talk about tag conformance when we=20 mean implementations. >=20 >> I think a two-year term is prudent. I don't think we need to have an=20 >> alternate. But the current, open-ended dictatorship is problematic to=20 >> me.=20 >=20 > It is *not* a dictatorship. Michael can be removed by petition to > the IESG. Furthermore, anyone who wishes to overturn a particular > decision may institute an appeal. You are right that my characterization is not correct. But it is beside=20 the point: I think that some review of performance is necessary. I note=20 that the reviewer must frequently be prodded into action. There is, even=20 now, a registration request that is many weeks old which has complete=20 consensus which Michael has apparently approved but not forwarded=20 (valencia). A regular renewal of the job would potentially improve=20 performance without resorting to the unpleasant appeals process. >=20 >> The Language Subtag Reviewer chairs the ietf-languages@iana.org=20 >> discussion list. The reviewer MAY delegate any list or other=20 >> administrative duties as necessary. As described in Section 3.5, the=20 >> reviewer is solely responsible for determining consensus on a=20 >> registration request and announcing the acceptance or rejection (or=20 >> extension of discussion) of any particular request.=20 >=20 > The LSR is not a moderator, but a judge. He does not announce, > but decides. We are his advisors. This is a revolutionary change. No. It's not or at least not intended to be. Or, to put it another way,=20 the reviewer has historically exercised broad (very broad) discretion in=20 accepting and rejecting requests. My understanding of RFC 4646 is that a=20 request that has met with broad consensus for inclusion and which=20 otherwise meets the requirements of the RFC won't unreasonably be=20 rejected. The reviewer is, as you say, a judge---s/he adjudicates=20 whether sufficient consensus has been achieved, and, furthermore, that=20 there are no fatal technical objections to the registration. This is why=20 the person is considered by IANA to be an "expert reviewer". If you don't like my proposed words to indicate this, do me the favor of=20 proposing better ones. I do note that Mark rather deeply changed the current draft's words, so=20 my edit might be unnecessary. The current editor's copy says: -- The Language Subtag Reviewer is appointed by the IESG for an indefinite=20 term, subject to removal or replacement at the IESG's discretion. The=20 Language Subtag Reviewer moderates the ietf-languages mailing list,=20 responds to requests for registration, and performs the other registry=20 maintenance duties described in Section 3.3 (Maintenance of the=20 Registry). Only the Language Subtag Reviewer is permitted to request=20 IANA to change, update, or add records to the Language Subtag Registry.=20 The Language Subtag Reviewer MAY delegate list moderation and other=20 clerical duties as needed. -- To this, I think it important to indicate that the LSR has the duty of=20 making the adjudication on a request. >=20 >> I'm okay with providing some guidance on tag choice and subtag orderin= g,=20 >> but not with more algorithm here. >=20 > "We'll argue that point," said Jack. > --_Mr. Midshipman Easy_ >=20 "That I never will, sir,=E2=80=9D replied Jack; =E2=80=9Cbut the next tim= e I argue it=20 shall be, if possible, with power on my side, and, at all events, not=20 quite so near a pond." I look forward to your argument :-). Addison --=20 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 Feb 27 17:55:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMBDr-0008M6-Jy; Tue, 27 Feb 2007 17:55:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMBDp-0008Ko-Vt; Tue, 27 Feb 2007 17:55:01 -0500 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMBDL-00088G-Db; Tue, 27 Feb 2007 17:54:47 -0500 Received: from localhost (localhost [127.0.0.1]) by mail2.sharplabs.com (Postfix) with ESMTP id D3BAF1E12F4; Tue, 27 Feb 2007 14:54:28 -0800 (PST) Received: from mail2.sharplabs.com ([127.0.0.1]) by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05579-10; Tue, 27 Feb 2007 14:54:23 -0800 (PST) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 89E3F1E12C9; Tue, 27 Feb 2007 14:54:22 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Feb 2007 14:54:22 -0800 Message-ID: <789E617C880666438EDEE30C2A3E8D100105A60A@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Bill Fenner' Subject: RE: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Ta g MIB) to Proposed Standard Date: Tue, 27 Feb 2007 14:54:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Virus-Scanned: amavisd-new at sharplabs.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ietf-languages@iana.org, Doug Ewell , LTRU Working Group , ietf@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Bill, Yes - from the IEEE/ISTO Printer Working Group, see the Job Monitoring MIB (RFC 2707) which defined the textual convention 'JmNaturalLanguageTagTC' on page 69. It uses max length 63 octets to be consistent with the earlier Internet Printing Protocol/1.0 (RFC 2566, now RFC 2911) that defined the datatype 'naturalLanguage' on page 67, also of max length 63 octets. Various printer vendor enterprise MIBs have imported this RFC 2707 textual convention or used this same max length (I wrote them at Xerox and Sharp, but I've seen others). Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Bill Fenner [mailto:fenner@gmail.com] Sent: Monday, February 26, 2007 7:29 PM To: McDonald, Ira Cc: John Cowan; Doug Ewell; ietf-languages@iana.org; LTRU Working Group; ietf@ietf.org Subject: Re: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Ta g MIB) to Proposed Standard On 2/10/07, McDonald, Ira wrote: > With respect to max length of 60, the public MIBs that > I'm aware of often use 63 octets Do you have any pointers? I searched my MIB object database for objects named "*Language*" or with DESCRIPTIONS with "Language" inside, and only got the IP-MROUTE-MIB and MALLOC-MIB ones. The MALLOC-MIB one was interesting, since it uses IPMROUTE-STD-MIB::LanguageTag(1..94). Thanks, Bill -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.4/705 - Release Date: 2/27/2007 3:24 PM _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 27 18:07:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMBQ1-0002bZ-MA; Tue, 27 Feb 2007 18:07:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMBQ0-0002b3-86 for ltru@ietf.org; Tue, 27 Feb 2007 18:07:36 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMBPv-000302-OM for ltru@ietf.org; Tue, 27 Feb 2007 18:07:36 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HMBPo-0007Aw-EF; Tue, 27 Feb 2007 18:07:24 -0500 Date: Tue, 27 Feb 2007 18:07:24 -0500 To: Addison Phillips Subject: Re: [Ltru] Proposals for changes to latest draft Message-ID: <20070227230724.GI1965@mercury.ccil.org> References: <30b660a20702270758y544a42bcl9d78f0806df8d05c@mail.gmail.com> <20070227195053.GB1965@mercury.ccil.org> <45E49284.4060107@yahoo-inc.com> <20070227204913.GE1965@mercury.ccil.org> <45E4A6CB.4080005@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45E4A6CB.4080005@yahoo-inc.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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: > I agree that this section will read better if we use Mark's definitions > based on tag conformance (allowing emails such as mine to pass muster). > But the section should then proceed to talk about applying the terms to > implementations. It makes no sense to talk about tag conformance when we > mean implementations. Let's have both, then: definitions of well-formed and valid tags, followed by definitions of validating and non-validating processors. > [T]he reviewer has historically exercised broad (very broad) discretion in > accepting and rejecting requests. My understanding of RFC 4646 is that a > request that has met with broad consensus for inclusion and which > otherwise meets the requirements of the RFC won't unreasonably be > rejected. Very well, provided the reviewer is the judge of what is reasonable! This reminds me of the lawyer's definition of "law", namely "the law is what the judge says it is." This works for lawyers, but not for judges, who are sworn to do justice according to law. > The reviewer is, as you say, a judge---s/he adjudicates > whether sufficient consensus has been achieved, and, furthermore, that > there are no fatal technical objections to the registration. This is why > the person is considered by IANA to be an "expert reviewer". Au contraire. I believe that the reviewer has *always* acted on his own judgement of whether the registration is good or bad, and *not* on the basis of what he thinks the list consensus is. I also believe that this is The Right Thing, as shown by actual practice. > > If you don't like my proposed words to indicate this, do me the favor of > proposing better ones. > > I do note that Mark rather deeply changed the current draft's words, so > my edit might be unnecessary. The current editor's copy says: > > -- > The Language Subtag Reviewer is appointed by the IESG for an indefinite > term, subject to removal or replacement at the IESG's discretion. The > Language Subtag Reviewer moderates the ietf-languages mailing list, > responds to requests for registration, and performs the other registry > maintenance duties described in Section 3.3 (Maintenance of the > Registry). Only the Language Subtag Reviewer is permitted to request > IANA to change, update, or add records to the Language Subtag Registry. > The Language Subtag Reviewer MAY delegate list moderation and other > clerical duties as needed. I'm good with that as far as it goes. > To this, I think it important to indicate that the LSR has the duty of > making the adjudication on a request. Sure. But I do not want to constrain him to do what the list thinks. He is not the list's servant, as an editor is; he is the sovereign expert (though with a provision to overrule him). > I look forward to your argument :-). Another day. -- May the hair on your toes never fall out! John Cowan --Thorin Oakenshield (to Bilbo) cowan@ccil.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Feb 27 19:27:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMCAz-0002zg-65; Tue, 27 Feb 2007 18:56:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMByo-00089b-Bg for ltru@ietf.org; Tue, 27 Feb 2007 18:43:34 -0500 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound5-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMBrd-0008E6-Oy for ltru@ietf.org; Tue, 27 Feb 2007 18:36:17 -0500 Received: from outbound5-blu.bigfish.com (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by outbound5-blu-R.bigfish.com (Postfix) with ESMTP id 8C4C1E41A88; Tue, 27 Feb 2007 23:34:25 +0000 (UTC) Received: from mail153-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound5-blu.bigfish.com (Postfix) with ESMTP id 3211DB30057; Tue, 27 Feb 2007 23:34:25 +0000 (UTC) Received: from mail153-blu (localhost.localdomain [127.0.0.1]) by mail153-blu-R.bigfish.com (Postfix) with ESMTP id BE83618B0111; Tue, 27 Feb 2007 23:34:24 +0000 (UTC) X-BigFish: VP Received: by mail153-blu (MessageSwitch) id 1172619264691915_7606; Tue, 27 Feb 2007 23:34:24 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail153-blu.bigfish.com (Postfix) with ESMTP id 530FEA80075; Tue, 27 Feb 2007 23:34:24 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007022715342291-79526 ; Tue, 27 Feb 2007 15:34:22 -0800 In-Reply-To: <20070227204913.GE1965@mercury.ccil.org> To: John Cowan Subject: Re: [Ltru] Proposals for changes to latest draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Tue, 27 Feb 2007 15:32:43 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 02/27/2007 15:32:43, Serialize complete at 02/27/2007 15:32:43, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 02/27/2007 03:34:22 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 02/27/2007 03:34:24 PM, Serialize complete at 02/27/2007 03:34:24 PM X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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="===============0103897087==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0103897087== Content-Type: multipart/alternative; boundary="=_alternative 00817D548825728F_=" This is a multipart message in MIME format. --=_alternative 00817D548825728F_= Content-Type: text/plain; charset="US-ASCII" John Cowan wrote: > Addison Phillips scripsit: > > > +1. Further, I'm not sure why one would tag content as "not written". > > Not including a script subtag does an admirable job of indicating the > > language in these cases. > > Omitting the script is technically ambiguous between "no script" and > "may or may not have a script, which may or may not be known". What > I would like to see proved is that this difference actually makes a > difference in practice. Typically other kinds of metadata will > differentiate textual from non-textual content. I think this is where I come out of hiding and repeat what I've previously stressed.... This matters to me. Distinguishing between a spoken variant used in dubbing and a written version used in subtitles is important. We maintain lists of valid "text languages" and "audio languages." These lists are unique with many similarities. This is how language is structured in most of the A/V standards I see. Of course, there are languages that fall outside of this including tactile languages and visual (sign languages). But to me, zh-cmn (dubbed) is totally different from zh-cmn-Hant (subtitled) and I think the idea of a spoken language having a suppressed script is silly. That's really bad data, IMHO. In short, I'd tag content as "not written" when it's spoken or signed. I never want to see a dubbing track identified as being Simplified Chinese. The suppress script tags in many ways makes RFC 4646 totally inappropriate for audio language tagging, but we also have no interest in using two different standards for the different uses. This is why I support text in RFC 4646bis that specifically indicates that audio languages should not be tagged with scripts -- they are inappropriate. From this perspective, ISO 639-6 makes a lot of sense to my industry. Outside of my immediate industry, there is a vast amount of video and animated content being added to the web every day. This needs tagging too. Regards, Karen Broome --=_alternative 00817D548825728F_= Content-Type: text/html; charset="US-ASCII"
John Cowan wrote:

> Addison Phillips scripsit:
>
> > +1. Further, I'm not sure why one would tag content as "not written".
> > Not including a script subtag does an admirable job of indicating the
> > language in these cases.
>
> Omitting the script is technically ambiguous between "no script" and
> "may or may not have a script, which may or may not be known".  What
> I would like to see proved is that this difference actually makes a
> difference in practice.  Typically other kinds of metadata will
> differentiate textual from non-textual content.

I think this is where I come out of hiding and repeat what I've previously stressed....

This matters to me. Distinguishing between a spoken variant used in dubbing and a written version used in subtitles is important. We maintain lists of valid "text languages" and "audio languages." These lists are unique with many similarities. This is how language is structured in most of the A/V standards I see.

Of course, there are languages that fall outside of this including tactile languages and visual (sign languages). But to me, zh-cmn (dubbed) is totally different from zh-cmn-Hant (subtitled) and I think the idea of a spoken language having a suppressed script is silly. That's really bad data, IMHO.

In short, I'd tag content as "not written" when it's spoken or signed. I never want to see a dubbing track identified as being Simplified Chinese. The suppress script tags in many ways makes RFC 4646 totally inappropriate for audio language tagging, but we also have no interest in using two different standards for the different uses.

This is why I support text in RFC 4646bis that specifically indicates that audio languages should not be tagged with scripts -- they are inappropriate. From this perspective, ISO 639-6 makes a lot of sense to my industry.

Outside of my immediate industry, there is a vast amount of video and animated content being added to the web every day. This needs tagging too.

Regards,

Karen Broome --=_alternative 00817D548825728F_=-- --===============0103897087== 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 --===============0103897087==-- From ltru-bounces@ietf.org Tue Feb 27 19:46:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMCwx-0000sq-Vb; Tue, 27 Feb 2007 19:45:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMCww-0000sl-RP for ltru@ietf.org; Tue, 27 Feb 2007 19:45:42 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMCwv-0003af-FA for ltru@ietf.org; Tue, 27 Feb 2007 19:45:42 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l1S0jSNO043921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Feb 2007 16:45:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=QbMXnEA/Fv4LBADw0UK8aHhJcUfulHKNqecAXU++MQ29InhDGo5c6Td4RgHkSEuA Message-ID: <45E4D0A8.2080104@yahoo-inc.com> Date: Tue, 27 Feb 2007 16:45:28 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Proposals for changes to latest draft 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: 244a2fd369eaf00ce6820a760a3de2e8 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 Karen_Broome@spe.sony.com wrote: > > This matters to me. Distinguishing between a spoken variant used in > dubbing and a written version used in subtitles is important. We > maintain lists of valid "text languages" and "audio languages." These > lists are unique with many similarities. This is how language is > structured in most of the A/V standards I see. I don't disagree with your purpose. I just note that you don't need a special language subtag to identify that the content is audio or otherwise non-texual. > > Of course, there are languages that fall outside of this including > tactile languages and visual (sign languages). But to me, zh-cmn > (dubbed) is totally different from zh-cmn-Hant (subtitled) and I think > the idea of a spoken language having a suppressed script is silly. > That's really bad data, IMHO. ?? I'm not sure what you mean by a "suppressed script". Suppress-Script is an informational field in the registry that advises users about the best form of tag to use for the written forms of languages. It has nothing to do with spoken or otherwise signaled forms of language. Various content is tagged with a language tag. The spoken/audio content is never tagged with tags that have a script subtag. The written content may include a script subtag (or not) depending on the usefulness of the script subtag in that context. It is entirely reasonable to think that a DVD might have an SAP track in "zh-cmn" and subtitling in "zh-cmn-Hant". > > In short, I'd tag content as "not written" when it's spoken or signed. I > never want to see a dubbing track identified as being Simplified > Chinese. The suppress script tags in many ways makes RFC 4646 totally > inappropriate for audio language tagging, but we also have no interest > in using two different standards for the different uses. It would be silly to tag an audio track as "Simplified Chinese", but the Content-Type (or equivalent) makes clear that something tagged "zh-cmn" is probably audio, nu? > > This is why I support text in RFC 4646bis that specifically indicates > that audio languages should not be tagged with scripts -- they are > inappropriate. Yes. This is just tag choice. The question here is whether we need to invent a fictional subtag to make clear that the content is "not written". There is an outer limit in the utility of coding everything in a language tag. Do you really want to see tags like "en-Qabx" for the English audio track? That's silly. "en" covers it just fine. 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 Feb 27 20:05:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMDFl-0002KO-OI; Tue, 27 Feb 2007 20:05:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMDFk-0002KJ-Iu for ltru@ietf.org; Tue, 27 Feb 2007 20:05:08 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMDFj-000709-4O for ltru@ietf.org; Tue, 27 Feb 2007 20:05:08 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l1S14oPK045364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Feb 2007 17:04:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=qdaS2Hy2ix+r8mE2MEkvmuJg0GwoUl0RQw3/BJxC4PvbD+ruvNDA3u9FVaUAjWnb Message-ID: <45E4D531.2030104@yahoo-inc.com> Date: Tue, 27 Feb 2007 17:04:49 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Proposals for changes to latest draft References: <30b660a20702270758y544a42bcl9d78f0806df8d05c@mail.gmail.com> <20070227195053.GB1965@mercury.ccil.org> <45E49284.4060107@yahoo-inc.com> <20070227204913.GE1965@mercury.ccil.org> <45E4A6CB.4080005@yahoo-inc.com> <20070227230724.GI1965@mercury.ccil.org> In-Reply-To: <20070227230724.GI1965@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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: > >> I agree that this section will read better if we use Mark's definitions >> based on tag conformance (allowing emails such as mine to pass muster). >> But the section should then proceed to talk about applying the terms to >> implementations. It makes no sense to talk about tag conformance when we >> mean implementations. > > Let's have both, then: definitions of well-formed and valid tags, > followed by definitions of validating and non-validating processors. Agreed. I thought that's what I said :-). > >> [T]he reviewer has historically exercised broad (very broad) discretion in >> accepting and rejecting requests. My understanding of RFC 4646 is that a >> request that has met with broad consensus for inclusion and which >> otherwise meets the requirements of the RFC won't unreasonably be >> rejected. > > Very well, provided the reviewer is the judge of what is reasonable! > This reminds me of the lawyer's definition of "law", namely "the > law is what the judge says it is." This works for lawyers, but not > for judges, who are sworn to do justice according to law. Yes, and hence the appeals process. > >> The reviewer is, as you say, a judge---s/he adjudicates >> whether sufficient consensus has been achieved, and, furthermore, that >> there are no fatal technical objections to the registration. This is why >> the person is considered by IANA to be an "expert reviewer". > > Au contraire. I believe that the reviewer has *always* acted on his > own judgement of whether the registration is good or bad, and *not* > on the basis of what he thinks the list consensus is. To be complete: the reviewer is sovereign in making the decision. However, the decision must be based on significant objections and these must be stated publicly on the list. List consensus or the lack thereof should certainly influence such a decision. My bigger concerns with the LSR historically have been: - there is a lack of timeliness in tracking the two-week rule - that acceptance or rejection is not always clearly made on the list (is, for example, 'valencia' going to show up some time soon or not?) - that objections are not always clear or clearly summarized - that criteria for registration/rejection are not always clear I believe that a registration in the face of overwhelming consensus against a subtag would be a truly bad thing. Similarly the reviewer should consider a countervailing consensus in support of a subtag closely before rejecting an item. The rejection cannot seem arbitrary: it must be based on something (RFCs 1766 and 3066 called this "significant objections", purposefully not defining "significant"). > I also believe > that this is The Right Thing, as shown by actual practice. Yes, when done well. It is the Wrong Thing when applied haphazardly and/or inconsistently. Mark's proposed changes to the term and nominating process would help ensure that this performance is occasionally monitored. > >> To this, I think it important to indicate that the LSR has the duty of >> making the adjudication on a request. > > Sure. But I do not want to constrain him to do what the list thinks. > He is not the list's servant, as an editor is; he is the sovereign expert > (though with a provision to overrule him). Good it is that I have not proposed we constrain him thus. I'm happy with the reviewer being the "sovereign expert", but the reviewer should also be aware that both "justice" and "the law" give a requester certain expectations of due process. I would not be concerned if there were a clear rejection of a subtag, even if it were entirely wrongheaded for the rejection to take place: the appeals process exists for precisely that purpose. 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 Wed Feb 28 02:34:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMJKC-0004JJ-Ap; Wed, 28 Feb 2007 02:34:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMJKA-0004He-1F for ltru@ietf.org; Wed, 28 Feb 2007 02:34:06 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMJK3-0005op-Ua for ltru@ietf.org; Wed, 28 Feb 2007 02:34:06 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l1S7XrlC014508 for ; Wed, 28 Feb 2007 16:33:54 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 39e5_0a9cece2_c6fe_11db_939f_0014221f2a2d; Wed, 28 Feb 2007 16:33:53 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:56113) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 28 Feb 2007 16:32:07 +0900 Message-Id: <6.0.0.20.2.20070228110754.0ad103c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 28 Feb 2007 11:09:00 +0900 To: Peter Constable , Mark Davis , Doug Ewell From: Martin Duerst Subject: RE: [Ltru] Progress In-Reply-To: <6.0.0.20.2.20070209154630.06f74560@localhost> References: <004b01c74b90$bb43b920$6801a8c0@DGBP7M81> <30b660a20702080656j151881eeg307a933bce10e5cf@mail.gmail.com> <6.0.0.20.2.20070209154630.06f74560@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Hello Peter, I haven't seen any news on this issue. Although we have other things to sort out, this one is crucial for our timeline, and so any info is appreciated! Regards, Martin. At 15:48 07/02/09, Martin Duerst wrote: >Hello Peter, > >What timeline do you expect for this cleanup work? >What is the chance that it can actually be done >(as opposed to being frozen because publication is already done)? > >Regards, Martin. > >At 10:50 07/02/09, Peter Constable wrote: >>Content-Language: en-US >>Content-Type: >multipart/alternative;boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB835795548891148ENAEXMSGC117re_" >> >>I can think of another reason: ISO Central Secretariat completed >publication faster than we expected: we thought they$BCE(B take a few weeks but >they posted it the very next day. We still have some details in the code >table wrt what to do with certain 639-2 entries that we$BCS(Be sorting out. Now >we have an unfortunate quandary: because of the ISO announcement, the >downloadable data files can be considered published even though there may >be a few things in there that are not ideal meaning we$BCE(B be stuck with >them. I wish we could clear those up before they got incorporated into a >4645bis draft. >> >>Peter >> >> >>---------- >>From: Mark Davis [mailto:mark.davis@icu-project.org] >>Sent: Thursday, February 08, 2007 6:56 AM >>To: Doug Ewell >>Cc: LTRU Working Group >>Subject: Re: [Ltru] Progress >> >>> 4646bis >> >>I can. Not all of my requests for changes have been considered (they may >of course be rejected, but that needs to be explicit). I will put together >a list and send to this group. >> >>Mark >>On 2/8/07, Doug Ewell <dewell@adelphia.net> wrote: >>ISO is reporting that ISO 639-3 has been published [1] and the ISO 639-3 >>Web site has been edited [2] and files renamed to remove the "FDIS" >>qualifier throughout. >> >>This removes our last external obstacle to moving RFC 4646bis and >>4645bis forward. Our goals were to submit these documents for IETF Last >>Call by the end of January, provided that ISO 639-3 had been published >>(the charter actually says "fully approved," which is surely implied by >>publication). As Mark might put it, it is now the 39th of January and >>we need to get moving if we are going to make the deadline. >> >>I have received no detailed comments on changes to be made in RFC >>4645bis, and will be completely ready to go in a day or so with a >>draft-02, intended for WG LC, that uses the (apparently final) 639-3 >>download tables. However, I don't think I'm supposed to do this unless >>4646bis is ready for WG LC as well (partly because of the lingering >>hex-NCRs question). Maybe there is some other reason we should be >>waiting and not taking action to move these documents forward, but I >>can't think of any. >> >>[1] >>http://www.iso.org/iso/en/CombinedQueryResult.CombinedQueryResult?queryString=639 >>[2] http://www.sil.org/iso639-3/ >> >>-- >>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 >>_______________________________________________ >>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 #-#-# 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 Feb 28 02:44:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMJUI-0003kA-9J; Wed, 28 Feb 2007 02:44:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMJUG-0003gw-7L for ltru@ietf.org; Wed, 28 Feb 2007 02:44:32 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMJUE-0007iv-Lb for ltru@ietf.org; Wed, 28 Feb 2007 02:44:32 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070228074421.HLWE27841.mta11.adelphia.net@DGBP7M81> for ; Wed, 28 Feb 2007 02:44:21 -0500 Message-ID: <002b01c75b0c$427f1b70$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 27 Feb 2007 23:44:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ltru] Re: Proposals for changes to latest draft X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > 2.2.3 bullet 6 adds the notion that the hitherto private tag Qabx is > to be usurped to mean "no written content". I agree that the > "unwritten languages" script tag does not do the job here, but I deny > that it is proper to steal a private-use tag, and I don't see any need > to have such an entity at all. Using Qabx was my idea, to replace Mark's original proposal to use Zxxx for this purpose. Zxxx is the ISO 15924 code element meaning "code for unwritten languages." I take that quite literally to mean "languages that do not have any commonly accepted writing system," which admittedly would be a rather odd piece of information to put in a language tag, and which is very different IMHO from "content that happens not to be in a writing system," such as signed or spoken content. This was my interpretation, but I confirmed it with Michael, the ISO 15924 Registrar. When an ISO standard that establishes a coding structure provides for private-use code elements, as ISO 639 and 3166 and 10646 and 15924 do, applications that use those standards are generally permitted to allocate code elements from the private space for their own needs. For example, CLDR uses the ISO 3166 private-use code element QO for "Outlying Oceania." We are permitted to do similarly for the Language Subtag Registry. I intentionally chose the last available ISO 15924 code as the least likely to cause conflict, since users of private codes tend to start at the bottom and work their way up, unless another approach yields better mnemonic value (which is in short supply among the 50 private codes in ISO 15924). Whether there is a need at all for a script subtag meaning "not written" is a battle I'll leave to others, but if there is, it should not be Zxxx. -- 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 Feb 28 03:29:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMKBZ-0003C1-Te; Wed, 28 Feb 2007 03:29:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMKBY-0003Bv-3n for ltru@ietf.org; Wed, 28 Feb 2007 03:29:16 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMKBV-0005wm-7x for ltru@ietf.org; Wed, 28 Feb 2007 03:29:16 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l1S8T9oh002403 for ; Wed, 28 Feb 2007 17:29:10 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 19ff_c3008b70_c705_11db_8dff_0014221fa3c9; Wed, 28 Feb 2007 17:29:09 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37533) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 28 Feb 2007 17:27:59 +0900 Message-Id: <6.0.0.20.2.20070228171927.066e2e30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 28 Feb 2007 17:27:27 +0900 To: Karen_Broome@spe.sony.com, John Cowan From: Martin Duerst Subject: Re: [Ltru] Proposals for changes to latest draft In-Reply-To: References: <20070227204913.GE1965@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Karen - A very simple (and maybe almost navie) question: I assume that language isn't the only thing that you tag for your material. I assume that there is other data, e.g. how long (time-wise) some piece of data is, ..., and most probably also whether something is audio, has subtitles, and so on. So what John is saying, and what I'm also assuming, is that if you know, from some other data that you have anyway, that something are subtitle, then you know that it must have some kind of script, where as if you youw from other data that it's audio, you know it can't have a script. Regards, Martin. At 08:32 07/02/28, Karen_Broome@spe.sony.com wrote: >John Cowan wrote: > >> Addison Phillips scripsit: >> >> > +1. Further, I'm not sure why one would tag content as "not written". >> > Not including a script subtag does an admirable job of indicating the >> > language in these cases. >> >> Omitting the script is technically ambiguous between "no script" and >> "may or may not have a script, which may or may not be known". What >> I would like to see proved is that this difference actually makes a >> difference in practice. Typically other kinds of metadata will >> differentiate textual from non-textual content. > >I think this is where I come out of hiding and repeat what I've previously stressed.... > >This matters to me. Distinguishing between a spoken variant used in dubbing and a written version used in subtitles is important. We maintain lists of valid "text languages" and "audio languages." These lists are unique with many similarities. This is how language is structured in most of the A/V standards I see. > >Of course, there are languages that fall outside of this including tactile languages and visual (sign languages). But to me, zh-cmn (dubbed) is totally different from zh-cmn-Hant (subtitled) and I think the idea of a spoken language having a suppressed script is silly. That's really bad data, IMHO. > >In short, I'd tag content as "not written" when it's spoken or signed. I never want to see a dubbing track identified as being Simplified Chinese. The suppress script tags in many ways makes RFC 4646 totally inappropriate for audio language tagging, but we also have no interest in using two different standards for the different uses. > >This is why I support text in RFC 4646bis that specifically indicates that audio languages should not be tagged with scripts -- they are inappropriate. From this perspective, ISO 639-6 makes a lot of sense to my industry. > >Outside of my immediate industry, there is a vast amount of video and animated content being added to the web every day. This needs tagging too. > >Regards, > >Karen Broome >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 28 09:41:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMPzI-0005UI-87; Wed, 28 Feb 2007 09:41:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMPzG-0005Kp-SJ for ltru@ietf.org; Wed, 28 Feb 2007 09:40:58 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMPzF-0005tj-Ge for ltru@ietf.org; Wed, 28 Feb 2007 09:40:58 -0500 Received: from [10.72.76.27] (snvvpn2-10-72-76-c27.corp.yahoo.com [10.72.76.27]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l1SEefAn094187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Feb 2007 06:40:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=xwRZmrmyqyCZfYvWpqp3pJl1nWoE7lKXHvqYLJGv9lbvIuePKIT+RZq0nPz0Ke10 Message-ID: <45E59469.1050804@yahoo-inc.com> Date: Wed, 28 Feb 2007 06:40:41 -0800 From: Addison Phillips User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Proposals for changes to latest draft References: <002b01c75b0c$427f1b70$6401a8c0@DGBP7M81> In-Reply-To: <002b01c75b0c$427f1b70$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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: > > When an ISO standard that establishes a coding structure provides for > private-use code elements, as ISO 639 and 3166 and 10646 and 15924 do, > applications that use those standards are generally permitted to > allocate code elements from the private space for their own needs. For > example, CLDR uses the ISO 3166 private-use code element QO for > "Outlying Oceania." We are permitted to do similarly for the Language > Subtag Registry. I don't much care for the usurpation of any of the private use codes. It is tantamount to assigning the code, given that BCP 47 is widely used. If people feel strongly about it, it might be wise to approach ISO 15924 and ask for a code assignment for the separate purpose of indicating "a language which could be written but happens not to be". > > Whether there is a need at all for a script subtag meaning "not written" > is a battle I'll leave to others, but if there is, it should not be Zxxx. > For reasons already stated: I don't see an actual use case for this subtag. Let me expound upon it here slightly. The presence of a script subtag indicates that the associated content is most likely textual and is written predominantly in that script. In the absence of a script subtag, a language tag may still *imply* a script in cases in which the content is text (that is, actually written) and the language is predominantly written in a single script (see: "Suppress-Script"), but this should not be taken to mean that the content *must* be text (written). The point of having an "anti-script" subtag would be to identify that content emphatically is not written. This would allow one to select (filter) the unwritten content using only the language tag (since one could use a language range that included the subtag). The problem is that most (I would say "all") such content has other, more salient features that describe the content as non-textual. On the Internet, for example, there is Content-Type. The problem here appears to be that some folks are not happy with a simple tag, such as "en" or (a better example) "sr", which makes no specific allusions to the script, because it isn't "exact" enough. Over-extending language tags or overburdening them with ancillary meaning does little good, while complicating the lives of users everywhere. Sometimes, simplicity is better than specificity. 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 Wed Feb 28 10:10:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQQq-0004h4-TZ; Wed, 28 Feb 2007 10:09:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQQh-0004N7-NE for ltru@lists.ietf.org; Wed, 28 Feb 2007 10:09:19 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMQIH-00086M-4M for ltru@lists.ietf.org; Wed, 28 Feb 2007 10:00:40 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HMQHf-000849-Ap for ltru@lists.ietf.org; Wed, 28 Feb 2007 15:59:59 +0100 Received: from d253042.dialin.hansenet.de ([80.171.253.42]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Feb 2007 15:59:59 +0100 Received: from nobody by d253042.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Feb 2007 15:59:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 28 Feb 2007 15:58:08 +0100 Organization: Lines: 9 Message-ID: <45E59880.1DC2@xyzzy.claranet.de> References: <30b660a20702270758y544a42bcl9d78f0806df8d05c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253042.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Ltru] Re: Proposals for changes to latest draft X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > http://docs.google.com/Doc?id=dfqr8rd5_4gh864p I'll wait for an Internet Draft - with 'rfcdiff' that gives me the usual style of diffs. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 28 10:11:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQSW-0006Jg-GJ; Wed, 28 Feb 2007 10:11:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQQY-0004JN-3I for ltru@ietf.org; Wed, 28 Feb 2007 10:09:10 -0500 Received: from mta16.mail.adelphia.net ([68.168.78.211] helo=mta16.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMQLE-0008Nf-Rh for ltru@ietf.org; Wed, 28 Feb 2007 10:03:43 -0500 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070228150336.SOCX3107.mta16.adelphia.net@DGBP7M81>; Wed, 28 Feb 2007 10:03:36 -0500 Message-ID: <004801c75b49$9f5b4ed0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <002b01c75b0c$427f1b70$6401a8c0@DGBP7M81> <45E59469.1050804@yahoo-inc.com> Subject: Re: [Ltru] Re: Proposals for changes to latest draft Date: Wed, 28 Feb 2007 07:03:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Karen_Broome@spe.sony.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > The presence of a script subtag indicates that the associated content > is most likely textual and is written predominantly in that script. In > the absence of a script subtag, a language tag may still *imply* a > script in cases in which the content is text (that is, actually > written) and the language is predominantly written in a single script > (see: "Suppress-Script"), but this should not be taken to mean that > the content *must* be text (written). Would it help to add an item to Section 4.1 (or elsewhere) stating that the absence of a script subtag may indicate non-written content, and should not automatically be interpreted as written content in the Suppress-Script? I couldn't find any such text in the current draft, based on a two-minute search on "script". I did find passages about not adding a script subtag unless it adds meaning to the tag, but that is an instruction to the tag generator (person or process), and what we apparently need is an instruction to the tag consumer. -- 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 Feb 28 11:13:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMRQN-0002Ys-Lt; Wed, 28 Feb 2007 11:13:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMRQL-0002Xt-Bk for ltru@lists.ietf.org; Wed, 28 Feb 2007 11:13:01 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMRQJ-0000L3-1Z for ltru@lists.ietf.org; Wed, 28 Feb 2007 11:13:01 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HMRQC-0004dg-51 for ltru@lists.ietf.org; Wed, 28 Feb 2007 17:12:52 +0100 Received: from d253042.dialin.hansenet.de ([80.171.253.42]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Feb 2007 17:12:52 +0100 Received: from nobody by d253042.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Feb 2007 17:12:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 28 Feb 2007 17:11:58 +0100 Organization: Lines: 31 Message-ID: <45E5A9CE.7C48@xyzzy.claranet.de> References: <002b01c75b0c$427f1b70$6401a8c0@DGBP7M81> <45E59469.1050804@yahoo-inc.com> <004801c75b49$9f5b4ed0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253042.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Ltru] non-written content (was: Proposals for changes to latest draft) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Would it help to add an item to Section 4.1 (or elsewhere) stating > that the absence of a script subtag may indicate non-written content No, that would be confusing. Most pre-4646 tags have no script subtag, because it didn't exist (excl. some Hans/Hant combinations, but that's also relatively new). An absent script subtag is no statement wrt. non-written content. The opposite is true, a present script subtag is nonsense for non-written content. okay : script subtag => written okay : not written => no script subtag (see below) wrong: no script subtag => not written wrong: written => script subtag > I did find passages about not adding a script subtag unless it adds > meaning to the tag That probably reflects "not written => no script subtag". > what we apparently need is an instruction to the tag consumer. Tag consumer aren't supposed to interpret the absence of a script subtag wrt written vs. not written. If Karen wants this info within the tags maybe she could use something like -x-text and -x-audio (?) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 28 14:29:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUUG-00038B-7D; Wed, 28 Feb 2007 14:29:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUUF-000383-JV for ltru@ietf.org; Wed, 28 Feb 2007 14:29:15 -0500 Received: from outbound-fra.frontbridge.com ([62.209.45.174] helo=outbound2-fra-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMUUB-0005Ab-Ag for ltru@ietf.org; Wed, 28 Feb 2007 14:29:15 -0500 Received: from outbound2-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-fra-R.bigfish.com (Postfix) with ESMTP id C14BC5E0DF6; Wed, 28 Feb 2007 19:29:10 +0000 (UTC) Received: from mail7-fra-R.bigfish.com (unknown [10.4.252.3]) by outbound2-fra.bigfish.com (Postfix) with ESMTP id BF275738058; Wed, 28 Feb 2007 19:29:10 +0000 (UTC) Received: from mail7-fra (localhost.localdomain [127.0.0.1]) by mail7-fra-R.bigfish.com (Postfix) with ESMTP id 8013A1014D; Wed, 28 Feb 2007 19:29:10 +0000 (UTC) X-BigFish: VP Received: by mail7-fra (MessageSwitch) id 1172690931375792_9972; Wed, 28 Feb 2007 19:28:51 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail7-fra.bigfish.com (Postfix) with ESMTP id 94F16A0003; Wed, 28 Feb 2007 19:28:48 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007022811284457-117745 ; Wed, 28 Feb 2007 11:28:44 -0800 In-Reply-To: <6.0.0.20.2.20070228171927.066e2e30@localhost> To: Martin Duerst Subject: Re: [Ltru] Proposals for changes to latest draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Wed, 28 Feb 2007 11:27:02 -0800 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 02/28/2007 11:27:04, Serialize complete at 02/28/2007 11:27:04, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 02/28/2007 11:28:44 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 02/28/2007 11:28:48 AM, Serialize complete at 02/28/2007 11:28:48 AM X-Spam-Score: 0.7 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 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="===============0536869632==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============0536869632== Content-Type: multipart/alternative; boundary="=_alternative 006AFF4988257290_=" This is a multipart message in MIME format. --=_alternative 006AFF4988257290_= Content-Type: text/plain; charset="US-ASCII" Responding to Martin and Addison: To clarify: I'm not requesting a subtag to indicate audio language. It might be useful, but we can indicate that through context. However, when I previously suggested text to make it clear that script tags should NEVER be used with audio language, I felt like the text that was ultimately added was watered down. I probably need to recheck the recent draft and make the suggestions again. I'm not sure why this was opposed as it's incredibly useful to anyone dealing with audio language. I don't think I want to tag audio language with an "unwritten" tag and agree that the language form can usually, but not always be determined through context. HTTP Content-Type doesn't help me much. I'm not writing web pages and I have both audio and dubbed languages identified in the same file. (I'm writing XML and using these in databases.) All I am really pushing for is a stronger "thou shalt not use script tags with audio content" as this isn't as obvious as you might think to the people who assign these tags (this problem extends beyond my employer). The Suppress-Script still bothers me, though I know my chances of getting this changed are nil. But for the purposes of argument: Addison writes: ?? I'm not sure what you mean by a "suppressed script". Suppress-Script is an informational field in the registry that advises users about the best form of tag to use for the written forms of languages. It has nothing to do with spoken or otherwise signaled forms of language. How does the registry know the "best" form of tag for any individual's usage? To me the "suppress" in suppress-script indicates "you needn't list this tag because it is the default for this language." The "best" form for my audio identification needs is most definitely not Latn and I'm not "suppressing" anything if I don't use the tag. The field isn't named "suggested-script." >From my viewpoint, indicating whether the language is spoken or written does fall under the concept of language identification and is not equivalent to proposals to include truly ancillary information that does not specifically serve to identify a language. This is where ISO 639-6 may offer a better alternative for many of my identification needs. It resolves the ambiguity of the "en" tag in RFC 4646. I'm going to Japan on Friday for a week and a half and probably won't be able to get to just about anything until I return, unfortunately. You could take another look at my previous suggestions with respect to not using script tags with audio content. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 Martin Duerst 02/28/2007 12:27 AM To Karen_Broome@spe.sony.com, John Cowan cc LTRU Working Group Subject Re: [Ltru] Proposals for changes to latest draft Karen - A very simple (and maybe almost navie) question: I assume that language isn't the only thing that you tag for your material. I assume that there is other data, e.g. how long (time-wise) some piece of data is, ..., and most probably also whether something is audio, has subtitles, and so on. So what John is saying, and what I'm also assuming, is that if you know, from some other data that you have anyway, that something are subtitle, then you know that it must have some kind of script, where as if you youw from other data that it's audio, you know it can't have a script. Regards, Martin. At 08:32 07/02/28, Karen_Broome@spe.sony.com wrote: >John Cowan wrote: > >> Addison Phillips scripsit: >> >> > +1. Further, I'm not sure why one would tag content as "not written". >> > Not including a script subtag does an admirable job of indicating the >> > language in these cases. >> >> Omitting the script is technically ambiguous between "no script" and >> "may or may not have a script, which may or may not be known". What >> I would like to see proved is that this difference actually makes a >> difference in practice. Typically other kinds of metadata will >> differentiate textual from non-textual content. > >I think this is where I come out of hiding and repeat what I've previously stressed.... > >This matters to me. Distinguishing between a spoken variant used in dubbing and a written version used in subtitles is important. We maintain lists of valid "text languages" and "audio languages." These lists are unique with many similarities. This is how language is structured in most of the A/V standards I see. > >Of course, there are languages that fall outside of this including tactile languages and visual (sign languages). But to me, zh-cmn (dubbed) is totally different from zh-cmn-Hant (subtitled) and I think the idea of a spoken language having a suppressed script is silly. That's really bad data, IMHO. > >In short, I'd tag content as "not written" when it's spoken or signed. I never want to see a dubbing track identified as being Simplified Chinese. The suppress script tags in many ways makes RFC 4646 totally inappropriate for audio language tagging, but we also have no interest in using two different standards for the different uses. > >This is why I support text in RFC 4646bis that specifically indicates that audio languages should not be tagged with scripts -- they are inappropriate. From this perspective, ISO 639-6 makes a lot of sense to my industry. > >Outside of my immediate industry, there is a vast amount of video and animated content being added to the web every day. This needs tagging too. > >Regards, > >Karen Broome >_______________________________________________ >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 --=_alternative 006AFF4988257290_= Content-Type: text/html; charset="US-ASCII"
Responding to Martin and Addison:

To clarify: I'm not requesting a subtag to indicate audio language. It might be useful, but we can indicate that through context. However, when I previously suggested text to make it clear that script tags should NEVER be used with audio language, I felt like the text that was ultimately added was watered down. I probably need to recheck the recent draft and make the suggestions again. I'm not sure why this was opposed as it's incredibly useful to anyone dealing with audio language.

I don't think I want to tag audio language with an "unwritten" tag and agree that the language form can usually, but not always be determined through context. HTTP Content-Type doesn't help me much. I'm not writing web pages and I have both audio and dubbed languages identified in the same  file. (I'm writing XML and using these in databases.)

All I am really pushing for is a stronger "thou shalt not use script tags with audio content" as this isn't as obvious as you might think to the people who assign these tags (this problem extends beyond my employer).

The Suppress-Script still bothers me, though I know my chances of getting this changed are nil. But for the purposes of argument:

Addison writes:

?? I'm not sure what you mean by a "suppressed script". Suppress-Script
is an informational field in the registry that advises users about the
best form of tag to use for the written forms of languages. It has
nothing to do with spoken or otherwise signaled forms of language.

How does the registry know the "best" form of tag for any individual's usage? To me the "suppress" in suppress-script indicates "you needn't list this tag because it is the default for this language."  The "best" form for my audio identification needs is most definitely not Latn and I'm not "suppressing" anything if I don't use the tag. The field isn't named "suggested-script."  

From my viewpoint, indicating whether the language is spoken or written does fall under the concept of language identification and is not equivalent to proposals to include truly ancillary information that does not specifically serve to identify a language. This is where ISO 639-6 may offer a better alternative for many of my identification needs. It resolves the ambiguity of the "en" tag in RFC 4646.

I'm going to Japan on Friday for a week and a half and probably won't be able to get to just about anything until I return, unfortunately. You could take another look at my previous suggestions with respect to not using script tags with audio content.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384


Martin Duerst <duerst@it.aoyama.ac.jp>

02/28/2007 12:27 AM

To
Karen_Broome@spe.sony.com, John Cowan <cowan@ccil.org>
cc
LTRU Working Group <ltru@ietf.org>
Subject
Re: [Ltru] Proposals for changes to latest draft





Karen - A very simple (and maybe almost navie) question:
I assume that language isn't the only thing that you tag
for your material. I assume that there is other data, e.g.
how long (time-wise) some piece of data is, ..., and
most probably also whether something is audio, has subtitles,
and so on.

So what John is saying, and what I'm also assuming, is that
if you know, from some other data that you have anyway, that
something are subtitle, then you know that it must have some
kind of script, where as if you youw from other data that it's
audio, you know it can't have a script.

Regards,    Martin.

At 08:32 07/02/28, Karen_Broome@spe.sony.com wrote:

>John Cowan wrote:
>
>> Addison Phillips scripsit:
>>
>> > +1. Further, I'm not sure why one would tag content as "not written".
>> > Not including a script subtag does an admirable job of indicating the
>> > language in these cases.
>>
>> Omitting the script is technically ambiguous between "no script" and
>> "may or may not have a script, which may or may not be known".  What
>> I would like to see proved is that this difference actually makes a
>> difference in practice.  Typically other kinds of metadata will
>> differentiate textual from non-textual content.
>
>I think this is where I come out of hiding and repeat what I've previously stressed....
>
>This matters to me. Distinguishing between a spoken variant used in dubbing and a written version used in subtitles is important. We maintain lists of valid "text languages" and "audio languages." These lists are unique with many similarities. This is how language is structured in most of the A/V standards I see.
>
>Of course, there are languages that fall outside of this including tactile languages and visual (sign languages). But to me, zh-cmn (dubbed) is totally different from zh-cmn-Hant (subtitled) and I think the idea of a spoken language having a suppressed script is silly. That's really bad data, IMHO.
>
>In short, I'd tag content as "not written" when it's spoken or signed. I never want to see a dubbing track identified as being Simplified Chinese. The suppress script tags in many ways makes RFC 4646 totally inappropriate for audio language tagging, but we also have no interest in using two different standards for the different uses.
>
>This is why I support text in RFC 4646bis that specifically indicates that audio languages should not be tagged with scripts -- they are inappropriate. >From this perspective, ISO 639-6 makes a lot of sense to my industry.
>
>Outside of my immediate industry, there is a vast amount of video and animated content being added to the web every day. This needs tagging too.
>
>Regards,
>
>Karen Broome
>_______________________________________________
>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    



--=_alternative 006AFF4988257290_=-- --===============0536869632== 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 --===============0536869632==-- From ltru-bounces@ietf.org Wed Feb 28 21:31: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 1HMb4Z-000571-O8; Wed, 28 Feb 2007 21:31:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMb4Y-00056r-MX for ltru@ietf.org; Wed, 28 Feb 2007 21:31:10 -0500 Received: from smtp1.wsfo.org ([208.145.81.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMb4T-0005jD-CJ for ltru@ietf.org; Wed, 28 Feb 2007 21:31:10 -0500 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp1.wsfo.org (8.13.1/8.13.1) with ESMTP id l212V2GO021261 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 28 Feb 2007 21:31:04 -0500 X-Scanned-By: MIMEDefang 2.54 on 172.22.0.51 X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp X-Scanned-By: This message was scanned by MPP Free Edition (www.messagepartners.com)! Received: from [203.154.79.169] (account martin_hosken@sil.org HELO [192.168.1.6]) by mail.link77.net (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 137996496 for ltru@ietf.org; Wed, 28 Feb 2007 21:31:01 -0500 Message-ID: <45E63AE0.9080102@sil.org> Date: Thu, 01 Mar 2007 09:30:56 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: LTRU Working Group X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Ltru] variants and ordering X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear All, Herewith my humble attempt to bring some order to a small area of chaos: variants. There are 3 major components to a language tag: language, script, region, each of which may take variants. In addition there may be variants to combinations of components. Regional information is used for locale information, and while I can see there may possibly be a need for regional variants, there is no evidence of their existence yet and certainly not of their interaction with the other components. So I will ignore them for the moment and perhaps return to them once a basic model is established. This leaves 2 components and therefore 3 types of variants: language variants, script variants and language+script variants which I will call orthography variants. The key concept I am proposing here is that variants are categorised, based on their prefix, as to what kind they are and then may be ordered in the tag based on that categorisation. A language variant takes a language only prefix. A script variant currently takes no prefix, but I propose that they take a script prefix. An orthography variant would take a language-script prefix (requiring both). Mark Davis has proposed a canonical ordering of variants within a tag: Any sequence of variant tags MUST be reordered such that for each variant subtags A and B, A comes before B if 1. A has no prefix and B has a prefix 2. or A and B are not ordered by #1, and A is part of a prefix (given the previous non-variant subtags) for B 3. or A and B are not ordered by #1 or #2, and A is alphabetically before B But this has been challenged with the example of en-scouse-fonipa. I.e. what people are saying is that language takes precedence over script, which makes perfect sense to me. I think the argument that one can say wider over narrower is unhelpful here since the two variants are from different categories. Based on this preamble, I propose the following: Any sequence of variant tags MUST be reordered such that for each variant subtag A and B, B comes before A unless any of the following are true: 1. A is a language variant and B is one of a script, orthography or regional variant or has no prefix 2. A is a script variant and B is one of an orthography or regional variant or has no prefix 3. A is an orthography variant and B is a regional variant or has no prefix 4. A is a regional variant and B has no prefix 5. A is part of a prefix for B 6. A is alphabetically before B Where a variant is considered: 1. A language variant if its prefix(es) or ancestoral prefix(es) consist only of language subtags 2. A script variant if its prefix(es) or ancestoral prefix(es) consist only of script subtags 3. An orthography variant if its prefix(es) or ancestoral prefix(es) consist only of language+script tags 4. A regional variant if its prefix(es) or ancestoral prefix(es) consist only of regional subtags Where the ancestoral prefixes are the prefixes of the ancestoral prefixes or the variant in question. The effect of this on the subtag registry is that a variant may only be of one kind and may not, for example, have a prefix list consisting of a language tag and then a script tag. Also script variants MUST take a script prefix rather than taking a blank prefix. In my analysis, I have treated orthography variants as being constrained script variants, local to a particular language and script. What makes script/orthography variants interesting is that, as has been stated in other discussion, their prefix script is implied and therefore is suppressed. Does this help? Yours, Martin Hosken _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Feb 28 22:03: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 1HMba6-0001VZ-I2; Wed, 28 Feb 2007 22:03:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMba4-0001VQ-Vh for ltru@ietf.org; Wed, 28 Feb 2007 22:03:44 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMba3-0007w5-M6 for ltru@ietf.org; Wed, 28 Feb 2007 22:03:44 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1HMba1-0006Xf-Bf; Wed, 28 Feb 2007 22:03:41 -0500 Date: Wed, 28 Feb 2007 22:03:41 -0500 To: Martin Hosken Subject: Re: [Ltru] variants and ordering Message-ID: <20070301030341.GD11472@mercury.ccil.org> References: <45E63AE0.9080102@sil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45E63AE0.9080102@sil.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.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 Martin Hosken scripsit: > But this has been challenged with the example of > en-scouse-fonipa. I.e. what people are saying is that language takes > precedence over script, which makes perfect sense to me. I think the > argument that one can say wider over narrower is unhelpful here since > the two variants are from different categories. Well, maybe it does and maybe it doesn't. A language variant may be less of a barrier than a script variant: as an American, I can understand Scouse fairly well either in spoken form or in more or less conventional orthography, but deciphering it in IPA (even though I know IPA) would be much more difficult. For that matter, the language-before-script rule doesn't even always apply correctly when non-variants are involved. For example, the standard language line in the Scandinavian Peninsula runs north and south, but the dialect isoglosses mostly run east and west. So a Norwegian can probably understand the speech of a Swede who lives at about the same latitude; but in written form, Danish is for historical reasons much more accessible than Swedish. > Based on this preamble, I propose the following: > > Any sequence of variant tags MUST be reordered such that for each > variant subtag A and B, B comes before A unless any of the following > are true: [detailed rules snipped] This is a set of rules for *creating* tags from existing subtags rather than for *canonicalizing* them, as Mark's proposals are. These are separate matters that shouldn't be confused. My take is as follows: 1) It's clear that en-scouse-fonipa and en-fonipa-scouse have different *matching* behaviors based on the RFC 4647 algorithms. 2) It's also clear, at least to me, that "en-scouce-fonipa" and "en-fonipa-scouse" *mean* the same thing, the Scouse dialect of English as recorded in IPA. 3) Canonicalization of tags is meant to eliminate non-semantic differences; therefore, it is sensible to have some set of canonicalization rules, even imperfect ones, to apply when multiple variant subtags are present. That does *not* mean that it's sensible to have restrictions on the order in which subtags are used to construct tags. -- In my last lifetime, John Cowan I believed in reincarnation; http://www.ccil.org/~cowan in this lifetime, cowan@ccil.org I don't. --Thiagi _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru