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 Ltru at ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.