Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote: >> 830 actually is a macrogeographical region, though it's a >> *small* macrogeographical region. > > It's not listed in the part with the macro-regions on their > page, it's still where it always was. This is true. I don't fully agree that 830 is intended as a macro code, regardless of where UNSD put it. I suspect they would not have added it in the first place if they had already had 831 and 832. > Let's just stick to the plan, whatever is true at "date B", > in Doug's "48 hours", gets a number. If they moved 830 to > "obsolete" don't list it, if they moved it to "macro-region" > keep it, and if their Web site is still unclear toss a coin. Frank and Mark are right. We don't want to open ourselves up to charges of "cherry-picking" the codes we want to use and ignoring the rest. Ultimately we are driven by the rules. The presence of both 830 *and* 831 and 832, none of which was permissible under RFC 3066, is not likely to cause any great difficulty in the real world. But it SHOULD be noted that if we do allow 831 and 832 (and 833), and if Addison is correct, we CANNOT subsequently register GG and JE (and IM) if those codes are added to ISO 3166/MA, and make them the Preferred-Values for the numeric codes. I think there is a common assumption that we (or ietf-languages) would do that. UN codes are used when there is no ISO code, but they cannot be superseded by ISO codes that are added later. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru at lists.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.