From: "Canaglobe International Inc." <mpereira@istar.ca> Date: Fri, 2 Oct 1998 12:49:40 -0400 3. The ISO 3166 standard Parts 1 and 2 is not IT-enabled, the two letter alpha codes are not stable can and do change (The IANA and Internet domain names also has to address this problem but then underneath all the Internat names are the numeric codes used for the actual routing and addressing among the ISPs, IT-systems, etc.). The ISO 3166 the three digit numeric country code is the most stable and also unique. True, but the 2-letter country codes are _much_ better known (especially now that they're part of Internet domain names), and they are much more common in most application areas served by POSIX and the ISO C standard. If you're going to use an ISO-based approach for locations, then the 2-letter codes are clearly the way to go. The 3-digit codes are not stable either, as locations change hands (the breakup of the Soviet Union being a recent example of wholesale reassignments). Since complete stability is impossible, we have to judge whether the 3-digit codes' slight increase in stability compensates for the increased number of user (and/or programmer) errors that are inevitable with numerical codes. In my view, the tradeoff is decisively in favor of the familiar alphabetic codes. P.S.I also agree that continent/citynames is not that useful. It neither provides the unambiguity nor uniques required for referencing purposes. Actually, he current setup is unambiguous and the names are unique. This is because there is a central registry of names. You are arguing for the substitution of a different central registry, one that is blessed by the ISO. Obviously this substitution will also work, and it might be more politically acceptable; but it is not strictly necessary to obtain uniqueness. 1. Reference the ISO 3166 standard 2. Always start with a Level one country code 3. The a level 2 administrative subdivision code (e.g. state, province, lander, canton, etc) Surely (3) is optional. Pitcairn doesn't have provinces. I assume that (3) is in US-ASCII. 4. The official name of the place according to the authoritative source, i.e. Wien and not Vienna or Vienne For interoperability reasons, names should be encoded in US-ASCII. Perhaps the standard could be extended to UTF-8 later, but I'm not sure the world is ready for UTF-8 here; and besides, even UTF-8 can't handle some place names. 5. Optional the associated lat/long coordinate as assigned by the authoritative source. In practice, there are many place names (even in the current tz database) for which there is no authoritative source. What is the authoritative source for the name of the South Pole Station, for example? (The people who live in the station use different names at different times, and would view a request for a canonical name with some amusement.) It will take the bureaucrats some time to catch up to reality; in the meantime we need something that works now. Therefore, (4) should be optional, and (5) should be a best guess in case there's no authority. 6. From a human interface needs and localization context, one would be free to provide different linguistic equivalent designations, i.e. "names" I suggest that there be a standard way for one of these designations to be an Olson-style name if one exists. This will encourage compatibility with existing practice, and will accommodate a gradual transition to the new order of things.