[Ltru] Re: Review of 4646bis-10, sections 3.5 to App. B
"Doug Ewell" <dewell@roadrunner.com> Sun, 09 December 2007 05:10 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 1J1ERB-0004U7-4R; Sun, 09 Dec 2007 00:10:45 -0500
Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1J1ERA-0004Pt-Aj for ltru-confirm+ok@megatron.ietf.org; Sun, 09 Dec 2007 00:10:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1ER9-0004Nl-UO for ltru@ietf.org; Sun, 09 Dec 2007 00:10:43 -0500
Received: from mta16.adelphia.net ([68.168.78.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1ER9-0007i3-5x for ltru@ietf.org; Sun, 09 Dec 2007 00:10: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 <20071209051042.BULS5365.mta16.adelphia.net@DGBP7M81> for <ltru@ietf.org>; Sun, 9 Dec 2007 00:10:42 -0500
Message-ID: <00b601c83a21$d947c3f0$6601a8c0@DGBP7M81>
From: Doug Ewell <dewell@roadrunner.com>
To: LTRU Working Group <ltru@ietf.org>
References: <E1J17Ll-000280-BI@megatron.ietf.org>
Date: Sat, 08 Dec 2007 21:10: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.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
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
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
Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote: > I'm aware of these "people", you're talking about John and me, and > John cried "doom". While I hate UTF-8 for the registry I never > doubted that IANA and reviewer will figure it out. IIRC John's "doom" > was also about folks discussing on a mailing list, and for that part I > still support it. Well, anyway, that's why there's a passage in 4646bis about making sure the UTF-8 doesn't get munged. Sorry if that seems like micromanagement. I thought there was at least one person who was sure the communication between LSR and IANA would never work. >> We didn't want chains, but even more so, we didn't want to break the >> stability of the Preferred-Value field. > > IOW we got it wrong, let's fix it while we're at it. "Stability of > Preferred-Value" makes no sense, the X -> Z shortcut for X -> Y -> Z > can't cause harm. Remember in LTRU 1.0 when we had an "issue tracker" ? Wouldn't that be handy right about now? >> Regarding cycles, I think if you want to rely on IANA and the LSR to >> get things right rather than adding MUSTard, you surely ought to give >> them (or at least me, as Co-Designated Expert) credit for detecting >> and avoiding cycles. > > But it was you who said that "un-drepecating" isn't allowed. It isn't. We're talking about Preferred-Value "cycles" of the form X -> Y -> X, right? 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. > Maybe you'd also say that adding Y -> X to a given X -> Y is at is, > because the X can't be "un-drepecated". For the hypothetical FX > example if we'd end up with FX deprecated in favour of FX it's > obvious, but longer cycles are harder to spot. 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. Not everything that is deprecated has to have a Preferred-Value anyway. >> This was added in direct response to fears expressed during LTRU 1.0 >> (which I did not share) that people would abuse private subtags. > > He-who-must-not-be-named will do what he likes, it's a waste of time > to tell the world how it has to judge such inventions. Actually 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": http://www.alvestrand.no/pipermail/ietf-languages/2004-June/002062.html > You *insist* on being an editor, for Addison that's a bit fictitious, > isn't it ? Inventing countries isn't what I consider as editorial > freedom. Addison wasn't the only one who wanted to add the exceptionally reserved 3166 codes; otherwise our arguments against it might have carried a bit more weight. 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. But anyway, Addison didn't "invent" Ascension Island and Clipperton and the rest; though he was quick to add them to the draft, most of the WG agreed with him. > If I wanted X months ago, and now want "not X" without saying that and > why I changed my mind, it's sad, but not intentionally bad, just point > it out. 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. That has cost us months and months of time that we could have spent moving forward. Replacing hex NCRs with UTF-8 is one of those decisions. I realize I'm also guilty of grumbling over lost battles, and I will try to stop doing that and look forward. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://home.roadrunner.com/~dewell http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru
- [Ltru] 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