[Ltru] Re: Review of 4646bis-10, sections 3.5 to App. B
"Frank Ellermann" <nobody@xyzzy.claranet.de> Sun, 09 December 2007 10:16 UTC
Return-path: <ltru-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1JDC-0001p1-LH; Sun, 09 Dec 2007 05:16:38 -0500
Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1J1JDA-0001oQ-Um for ltru-confirm+ok@megatron.ietf.org; Sun, 09 Dec 2007 05:16:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1JDA-0001oF-Kl for ltru@lists.ietf.org; Sun, 09 Dec 2007 05:16:36 -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 1J1JD9-0001Xs-V6 for ltru@lists.ietf.org; Sun, 09 Dec 2007 05:16:36 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J1JD2-0002vw-SO for ltru@lists.ietf.org; Sun, 09 Dec 2007 10:16:28 +0000
Received: from c-180-160-168.hh.dial.de.ignite.net ([62.180.160.168]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ltru@lists.ietf.org>; Sun, 09 Dec 2007 10:16:28 +0000
Received: from nobody by c-180-160-168.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ltru@lists.ietf.org>; Sun, 09 Dec 2007 10:16:28 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: ltru@lists.ietf.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Sun, 09 Dec 2007 11:18:23 +0100
Organization: <http://purl.net/xyzzy>
Lines: 78
Message-ID: <fjgf9i$e4q$1@ger.gmane.org>
References: <E1J17Ll-000280-BI@megatron.ietf.org> <00b601c83a21$d947c3f0$6601a8c0@DGBP7M81>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: c-180-160-168.hh.dial.de.ignite.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
X-Spam-Score: -0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc:
Subject: [Ltru] Re: Review of 4646bis-10, sections 3.5 to App. B
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Errors-To: ltru-bounces@ietf.org
Doug Ewell wrote: > We're talking about Preferred-Value "cycles" of the form > X -> Y -> X, right? Yes, e.g. MY changing its name (and code) back to BU. It could be more convoluted. > If you're not confident we're going to cross-check for > such things anyway, looking at the Deprecated field > probably isn't going to help us much. IMO you can't add a new "deprecated, now use BU" to MY, and keep the old "deprecated, now use MY" in BU. You also can't say that the "new" BU is a collision with the old BU, and therefore MY needs a "deprecated, now use UN number". Somebody, it wasn't me, had a "same piece of land" plausibility test for such weird scenarios, that used to produce good results. [longer chains] > I think I could spot them. It's not as if we are > going to have dozens and dozens of deprecated subtags > that we can't keep track of. Likely you can, actually that's the idea, if you get it right, and if you update the Preferred-values, then we don't need to worry that everybody else get this right (in implementations or other uses of "chained" records) > I was thinking of Harald's review of a pre-LTRU draft, > in which he first wrote "Private-use subtags are simply > useless for information exchange without prior arrangement" He's right, but it's IMO no surprise worth to be noted in the RFC, immediately followed by a "MAY be not useless". > This is an interesting topic for you and me to discuss, > because we disagree with the (unofficial) rough consensus > for opposite reasons: I don't like changing the rules to > treat the EU as a country for language ID purposes; you > are OK with the EU but don't like the islands and Spanish > Africa. Oops, no, I also don't like EU, sorry if that was unclear. Very remotely EU might make sense, but s/QU/EU/ in CLDR won't help them with QO, besides they're free to use EU now as far as I'm concerned. And "very remotely" means "long after UK was registered as deprecated in favour of GB (or vice versa)", I also don't like UK after the years of LTRU brain washing. I still remember that folks can confuse UK with GB for obvious reasons in real language tags - for EU I've difficulties to imagine a real use in a language tag. For the rest of the zoo I can imagine how registering EA might help to start a war, or end up as "evidence" in a UK (or GB :-) court case related to DG. >> In cases such as "UTF-8 instead of NCRs" I want tons >> of "not X" because the former X was designed to work >> with NCRs. > I really don't want to go back over decisions that have > been made. You wanted UTF-8, now we have to fix the rest of the draft a.k.a. eating our dogfood. "72" (and arguably "folding") were not designed for UTF-8, they were designed for "view an NCR registry as ASCII". Demoting "72" to SHOULD while keeping "folding" as defined in RFC 822 (i.e. no grapheme folding, just don't if you can't) is as constructive as I can manage it for this modification. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru
- [Ltru] Review of 4646bis-10, sections 3.5 to App.… John Cowan
- [Ltru] Re: Review of 4646bis-10, sections 3.5 to … Frank Ellermann
- [Ltru] Re: Review of 4646bis-10, sections 3.5 to … Doug Ewell
- [Ltru] Re: Review of 4646bis-10, sections 3.5 to … Frank Ellermann
- [Ltru] Re: Review of 4646bis-10, sections 3.5 to … Stephane Bortzmeyer
- [Ltru] Re: Review of 4646bis-10, sections 3.5 to … Frank Ellermann
- [Ltru] Re: Review of 4646bis-10, sections 3.5 to … Doug Ewell
- Re: [Ltru] Re: Review of 4646bis-10, sections 3.5… John Cowan
- Re: [Ltru] Re: Review of 4646bis-10, sections 3.5… John Cowan
- [Ltru] Re: Review of 4646bis-10, sections 3.5 to … Frank Ellermann
- [Ltru] Re: Review of 4646bis-10, sections 3.5 to … Frank Ellermann
- Re: [Ltru] Re: Review of 4646bis-10, sections 3.5… John Cowan
- [Ltru] Re: Review of 4646bis-10, sections 3.5 to … Doug Ewell
- [Ltru] Re: Montenegrin what-if Doug Ewell
- [Ltru] Re: Review of 4646bis-10, sections 3.5 to … Frank Ellermann
- Re: [Ltru] Re: Review of 4646bis-10, sections 3.5… Martin Duerst
- Re: [Ltru] Re: Review of 4646bis-10, sections 3.5… John Cowan
- Re: [Ltru] Re: Review of 4646bis-10, sections 3.5… Mark Davis
- [Ltru] Re: Review of 4646bis-10, sections 3.5 to … Stephane Bortzmeyer
- [Ltru] Re: Review of 4646bis-10, sections 3.5 to … Frank Ellermann
- Re: [Ltru] Re: Review of 4646bis-10, sections 3.5… Martin Duerst
- Re: [Ltru] Re: Review of 4646bis-10, sections 3.5… John Cowan
- [Ltru] Re: Review of 4646bis-10, sections 3.5 to … John Cowan