john, your eloquently told story agrees with personal memory and my particular version of reality ;-). I know for a fact that ISO3166 at the time contained at least two letter alphabetic, three letter alphabetic and numeric codes for each country or territory recognized by the United Nations. I also distinctly remember a number of conversations with Jon about DNS "going international". Jon wisely saw that IANA needed an external authority to decide what was a country. After considering several such authorities, the United nations appeared the most widely agreed one. >From there it was but a short step to ISO3166. The choice for two letter alphabetic codes was also straightforward: there were no two letter TLDs at the time and that guaranteed that there would be no clashes with exiting TLDs. [1] So I would argue that ASCII ccTLDs are indeed meant to be exactly two letters. If only to avoid clashes with future changes to ISO3166 I would consider it to be a Bad Idea to allocate two letter ASCII strings for any other purpose. This is why I have spoken up against ".EU" until the ISO3166 maintenance agency published it as a "reserved" code. Conversely it would be problematic now to have three letter ASCII ccTLDs unless there is a clear agreement with ISO that they will never allocate a three letter code that already exists as a gTLD. Afaik there are no clashes right now, but past results are not a guarantee for the future. It is never a good idea to have two 'authorities' over one part of a name space. dfk [1] UK appeared at different times in at least two realities that have been recounted to me. ;-) But there was no clash in ISO3166 at the time. On 1.01.70 1:00 , wrote: > > > --On Friday, June 30, 2017 07:31 +0200 Olivier MJ > Crépin-Leblond <ocl@xxxxxxx> wrote: > >> Hello all, >> >> I am reading RFC1591 and RFC3071 and have a couple of simple >> questions: 1. Is a ccTLD defined as restricted to 2-letter >> country codes (ISO3166 alpha 2), or could that include >> 3-letter country codes in the ISO3166 list (ISO3166 alpha 3)? >> 2. RFC1591 appears to point at 2-letter, but many other parts >> of this RFC are obsolete - so does this RFC remain valid? > > Olivier, > > First, it is important to understand that RFC 1591 was never an > IETF document. It was an IANA policy document, dating from a > time that IANA operated largely independent of the IETF (the > IETF could _request_ registration actions or registry creation, > but not _order_ them and so could others) and, while it > (deliberately, IIR) didn't strongly call that out, reflecting > policies and norms that had been in effect, although evolving > somewhat, long before the time it was published. > > It may also be useful to recall that the practical authority of > IANA in the DNS space at that time was derived from two things. > The first is what is known (especially next week) on this side > of the pond as the "consent of the governed": just about > everyone understood that a central registration and allocation > authority was important and, with one important exception [1], > no one had something they believed was a better idea that they > were anxious to propose. Yes, in theory the US Government could > have stepped in, but they didn't and their behavior was such as > to lead everyone to believe that they wouldn't. The second was > that there was a general belief that, if the rules, especially > those involving principles of responsible behavior that 1591 > invokes with the "trustee for the ... community" language, were > violated IANA had both the authority and the will to, e.g., make > changes in delegations to parties who would be more responsible. > > There were also a number of things -- both "rules" and > explanations -- that didn't go into 1591, either because we > didn't think of them (or think they were necessary) or because > Jon saw them simply as things he wasn't going to allow. The > now-famous "will be alphabetic" phrasing in RFC 1123 about TLD > labels was typical: Jon knew he simply was not going to allow > TLD names containing anything other than ASCII letters. > > Whether the principles underlying 1591 are "obsolete" or not > depends on some complicated questions involving one's view of > the Internet and the role of the DNS (see > draft-klensin-dns-function-considerations as well as several > RFCs that followed 1591. Certainly, when 1591 was written, we > didn't anticipate either ICANN or the rise of the domain name > business (and, arguably, its dominance in decision-making). > > Now, with that background, let me try to answer your question. > First, the ccTLD naming model was strictly limited to allocated > codes in what is now called ISO 3166-1 alpha-2 [1]. > Specifically, no use of the reserved list (not sure that existed > at the time either), no private-use codes, no codes allocated by > IANA rather than a body fully responsible to ISO TC 46, and, > while there are a couple of famous mistakes (history and > explanation on request if relevant) no allocations on > speculation. > > One of those rules was, AFAKK, never formally published although > at least part of it was widely understood. That was that TLD > labels came in categories that could be determined by length, > such that filters and algorithms could be based on those > categories. The rule was 2-3.4+, i.e., > > * All two-letter labels were country codes derived from > 3166 alpha-2. > * All three letter labels were generic TLDs (not all of > which were managed under IANA supervision). > * All labels of four characters or more were either the > specific string "ARPA" (which was originally intended to > be temporary and transitional) or what is now known as a > "special use name", i.e., one that is not part of the > global DNS or that was expected to be processed using > some non-DNS mechanism. > > ICANN staff were warned about that rule in the 1999 period but > decided to allow TLD applications for gTLDs with labels longer > than three characters and to not identify the issue to > applicants. Many of the issues that are now seen as "universal > acceptance" problems are the result of that decision. Whether > one assumed at the time, or concludes now, that it was a > rational, consensus, decision to favor applicant choice and > consequent competition in the TLD marketplace over that > historical rule or, even the controversies about special names, > a screwup and/or show of arrogance is very much in the mind of > the beholder. > > Similarly, ICANN clearly broke the 1591 rules in allocating "EU" > as a TLD label. It is not an ISO 3166-1 alpha-2 registered > country code and it violates some territorial overlap rules that > are intrinsic to bother 3166-1 and the assumptions underlying > 1591. At a different end of the problem, IANA's rules (pointed > to but maybe not explicit enough) is that, if a country > convinced 3166/MA to change its code, there needed to be a plan > in place to remove the older TLD within a reasonably short > period before the new code would be delegated (on a "one > territory, one code" principle)). IIR, there was such an > agreement about "SU" before "RU" was delegated, but ICANN has > never succeeded in getting rid of "SU", violating that principle. > > All of this is further complicated by IDN TLDs, where new ones > associated with countries are not limited to two characters > (even in their original scripts); non-country political entities > are allowed (if one counts GOV. MIL, and maybe INT, they have > always been allowed, but those are probably a bit different(; > and the relationships between 3166 alpha-2 ccTLDs and their IDN > relatives have never really been spelled out (despite the length > of the ccTLD Fast Track Procedure. > > Whether that makes 3166 partially or completely obsolete is a > matter of personal judgment. Because it was an IANA document, > the IETF Protocol Police would never have arrested anyone for > violating it. Unlike the IETF and its relationship to the > Protocol Police, IANA did have the ability to enforce its > provisions (and did). ICANN has clearly demonstrated a > willingness to violate some of its provisions (explicit or > implied) and it appears that, both prior and subsequent to the > recent "IANA transition", there is no one to tell them that they > cannot do so. My personal opinion that the Internet would be > much better off if the principles of 1591, especially the > requirement that registries be required to act in the best > interests of the global Internet community, were followed and > enforced (see draft-klensin-idna-rfc5891bis for the specific > IDNA case) are probably worth a cup of fancy coffee after a few > Euros (or equivalent) are thrown in. > > best, > john > > > [1] The dissenters were largely arguing for abandoning the DNS > in favor of X.500. At least in public, that position was > justified on the basis of developing and future technology, with > the side effect of putting the top-level entities under the > control of the ISO and ITU registration processes. > Interestingly, with regard to your question, X.500 uses ISO > 3166-1 alpha-2 country codes as well. > > [2] I don't think there was more than one part of ISO 3166 at > the time Jon discovered or was pointed to the Standard and can't > remember if it contained the alpha-3 codes in addition to the > alpha-2 and numeric ones. I do know that we never considered > anything other than the alpha-2 codes for ccTLD names, if only > because Jon wanted that system to be as deterministic as > possible with no possibility about arguments about what code > should be assigned that IANA needed to referee. > > >