Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote: >> 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. > > If they deprecate 830 too late we also deprecate it => ready. True. >> 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. > > Not my assumption. I got the idea that 3066bis is a one-way > street to UN numbers in slow motion. I did not get that idea, unless by "slow motion" you mean hundreds and hundreds of years. <soapbox> The great pace of national change, fueled by the national self-determination of colonial holdings during the 20th century and the rise of nationalism during the 19th and 18th, has essentially concluded. Most nations on Earth -- probably 75% or more -- have attained more or less the same status they will continue to have for many, many years to come. Even the great changes of the 1990s -- the breakup of the Soviet Union and Yugoslavia, the reunification of Germany and Yemen -- affected fewer than 10% of the currently recognized nations. Minor changes in governmental structure will not materially affect the relevancy of ISO 3166; changes in name or other major changes are not likely to occur at the pace necessary to render ISO 3166 worthless for our purposes. I expect to be around in 50 years to see how well these predictions have held up. :-) </soapbox> > You (all here) didn't > like my plan to do this fast (at date-B) and for all regions. I did not. We have to stay backward compatible with RFC 3066, and that means sticking with alpha-2 region subtags. I will not argue this further. > As long as GG, IM, and JE still _can_ be listed a.s.a.p. it's > no real problem if their Preferred-Value sticks to 831...833. I don't believe they can be added if 831 through 833 already exist. Addison and Mark can confirm or deny this. >> they cannot be superseded by ISO codes that are added later. > > Is there a "normal" procedure that the UN numbers are "always" > changed first, and that 3166-1 follows suite later ? We could > add some text to the draft allowing for this delay, avoiding > premature registrations of unnecessary / redudant UN numbers. ISO 3166/MA states that they do not add a code for a country unless it appears in the UN list. This allows them to avoid the controversy of "defining" what is a country, while giving them authority to assign codes to the things the UN has defined as countries. This is as it should be. So yes, there is a procedure that UN coding comes before ISO. What ISO does not promise is that UN coding *will automatically* lead to ISO coding. So far it seems to have happened 100% of the time, even for Åland, which is why I suggested waiting until ISO made a decision before adding subtags for these entities. But many people have pointed out that we can't delay the draft indefinitely, waiting for ISO to make a decision. (They're not known for adhering to published schedules in doing so.) Later: > In the hypothetical case TP -> TL, and TL changing its name > again, we get TP -> TL and TL -> XX. Is that really necessary, > why not just update TP -> XX in this case ? A very minor nit. I would greatly prefer this, but it seems not to have met with much approval. > | Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do > | not conflict with existing subtags of the associated type and > | whose meaning is not the same as an existing subtag of the > | same type are entered into the IANA registry as new records > | and their value is canonical for the meaning assigned to > | them. > > That's apparently an error, let's say "ISO 3166, and UN M.49" > instead of (only) "and ISO 3166". No, that's on purpose. ISO alpha-2 codes are considered the standard form for region subtags, while UN M.49 numeric codes are considered a fallback in case the ISO approach causes problems (as with CS) or for the macrogeographical regions that are outside the scope of ISO 3166. UN codes and ISO 3166 codes do not supersede one another. > And where's the rule about a new code that does _not_ conflict > with an existing code, but whose meaning _is_ the same as an > existing subtag ? The TL -> XX in my example ? We should > simply delete this part resulting in: > > Codes assigned by ISO 639, ISO 15924, ISO 3166, and UN M.49 > that do not conflict with existing subtags of the associated > type are entered into the IANA registry as new records and > their value is canonical for the meaning assigned to them. If an ISO code does not conflict with an existing subtag, and has the same meaning as an existing subtag, aren't they the same code? I must be missing something here. Give me a example of what you mean. > Adding a statement about the "same meaning" case: > > If existing codes have the same meaning a Preferred-Value is > added or updated to show the new code. UN M.49 codes are > only added if no ISO 3166 code with the same meaning exists. > > In this form GG, IM, and JE would replace 831..833. I think I understand what you mean. It would have to be up to the WG to decide, at this very late stage, whether to change the policy in this way. > This isn't > what we think how it should work, something with my proposal is > still wrong. But something in draft -04 is also still wrong. Understandably, Randy will want something more concrete than this. -- 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.