John Cowan <cowan at ccil dot org> wrote: >> Should we consider incorporating the 639-5 code elements into >> draft-4645bis? > > I think we should do so, despite 639-5 being technically off-charter. Heck, we've spent a great deal of the past two years going off-charter. This is at least more closely related to charter work than some things we've done. > There are no exact definitions of either the old 639-2 or the new > language collections, but if we identify them with their obvious > counterparts from the Ethnologue, I think these six cases require > special consideration: Arrggh. I hate all this cherry-picking, even though it seems to be our only path to internal agreement: no extlangs except for 'zh-*' (and maybe 'sgn-*' and 'ar-*', we can't decide), no more ISO 639-1 codes even if ISO assigns them, add ISO 639-5 codes except for these five. I should add the one where we add ISO 3166 exceptionally reserved codes except 'UK', which is actually an exception to an exception. At least that one is based on a rule we already have about not adding exact duplicates at registration time; it applies the rule to RFC 4645bis publication time as well. Still, it is yet another exception from the ISO standards. I am reminded that back in late 2004, when the ietf-languages group had already worked on 3066bis (as an individual submission) for over a year and it went to IETF Last Call, we were harshly criticized for cherry-picking ISO country codes. (The main focus at the time was on interpreting 'CS' as Czechoslovakia versus Serbia and Montenegro; we didn't have the Date A/B thing worked out yet.) We were criticized for appearing to take over the role of ISO MAs and RAs, second-guessing which ISO codes should and should not exist and what they should mean. It would be a real shame if this happened again. Since this WG is under the threat of being shut down -- I know Randy probably intends it more as a motivator than a threat, but the effect is the same -- I understand we need to work out compromises, and quickly. I just hope we are prepared to defend our decisions when we finally go to IETF LC and reviewers ask why we know better than this or that RA. -- Doug Ewell * Arvada, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org 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://www.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.