--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.