Subject: [Ltru] Re: Review of 4646bis-10, sections 3.5 to App. B

From: "Doug Ewell" <[email-masked]>
Date: Sat, 8 Dec 2007 21:10:42 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Sun, 9 Dec 2007 00:44:57 -0500

> between LSR and IANA would never work.

That would be me.  I'm still more than doubtful, and will be very quick
with the ITYS when there's corruption in the registry for the first time.

-- 
Even a refrigerator can conform to the XML      John Cowan
Infoset, as long as it has a door sticker       [email-masked]
saying "No information items inside".           http://www.ccil.org/~cowan
        --Eve Maler

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 9 Dec 2007 11:18:23 +0100

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

---

From: John Cowan <[email-masked]>
Date: Sun, 9 Dec 2007 11:27:27 -0500

> MY, and keep the old "deprecated, now use MY" in BU.

Clearly not.

> with the old BU, and therefore MY needs a "deprecated,

Why not?

-- 
Take two turkeys, one goose, four               John Cowan
cabbages, but no duck, and mix them             http://www.ccil.org/~cowan
together. After one taste, you'll duck          [email-masked]
soup the rest of your life.
        --Groucho

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 10 Dec 2007 05:34:56 +0100

John Cowan wrote:
 
  ["my BU": there and back again]
 
> Why not?

It fails in a giggle test, like the "revived FX" example.

 Frank