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

["Doug Ewell" <[e-mail]>]

Frank Ellermann <nobody at xyzzy dot claranet dot de> 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.
> ...
> 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".

Draft-4646bis-10, section 3.4 says:

<quote>
14.  Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict 
with existing subtags of the associated type, including subtags that are 
deprecated, MUST NOT be entered into the registry. The following 
additional considerations apply to subtag values that are reassigned:

D.  For ISO 3166 codes, if the newly assigned code's meaning is 
associated with the same UN M.49 code as another 'region' subtag, then 
the existing region subtag remains as the preferred value for that 
region and no new entry is created. A comment MAY be added to the 
existing region subtag indicating the relationship to the new ISO 3166 
code.

E.  For ISO 3166 codes, if the newly assigned code's meaning is 
associated with a UN M.49 code that is not represented by an existing 
region subtag, then the Language Subtag Reviewer, as described in 
Section 3.5 (Registration Procedure for Subtags), SHALL prepare a 
proposal for entering the appropriate UN M.49 country code as an entry 
in the IANA registry.
</quote>

So if UNSD retains the M.49 numeric code 104 for the new "Burma," as 
they did when the name was changed to Myanmar, then the subtag MY 
remains as is.  If UNSD changes their policy as does assign a new 
numeric code, say 105, then the numeric code 105 would be registered for 
"Burma" and MY would be deprecated with a Preferred-Value of 105.  This 
is unequivocal, and appears to be the same text as in RFC 4646.  Is 
there a compelling reason to change this LTRU 1.0 decision?

> Somebody, it wasn't me, had a "same piece of land"
> plausibility test for such weird scenarios, that used
> to produce good results.

That was me, as you know, and that seat-of-the-pants test mentioned in 
one e-mail was rightly replaced by an objective test based on UN M.49.

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

There are two issues being discussed together here:

1.  "Chained" Preferred-Values such as i-hak -> zh-hakka -> hak.   IIRC, 
this is the only example so far, but there could easily be more in the 
future.  These are not that hard to implement, and the worst-case 
scenario if someone doesn't follow the chain is that a deprecated subtag 
gets replaced by another deprecated subtag, which is not devastating.

2.  "Cycles" of Preferred-Values caused by inappropriate chaining.  One 
of Frank's examples was BU -> MM -> BU.  If we follow Section 3.4 (14) 
quoted above, this should never happen, and even if there is some 
scenario not covered by Section 3.4 (14) it is the responsibility of the 
Reviewer and his elves, NOT end users, to prevent this from happening.

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

Perhaps you may want to debate the point with Harald.  (I happen to 
agree with you that the warning isn't really necessary, but see no real 
harm in it.)

> Oops, no, I also don't like EU, sorry if that was unclear.

I take that back; it was UK that you said you didn't have a problem 
with.  My apologies.

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

While I don't understand the 72-byte limitation either (though I could 
understand a 72-character limitation), I don't see what the big deal is, 
or why UTF-8 "breaks" the existing folding algorithm.  In practice, for 
scripts that use white space between words (Latin, Greek, Cyrillic, 
Arabic, Hebrew, etc.) the algorithm will be reduced to "fold on white 
space."  For some East Asian scripts, it gets more complex, but I don't 
see why it is a showstopper.

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