Re:

[Daniel Karrenberg <[e-mail]>]

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 <[e-mail]> 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.    
> 
> 
>