Summary

  • RFC 3071 proposed classifying top-level domains by registration practice and constituency, not by whether their labels were two-letter country codes.
  • ISO-code eligibility, root delegation, a registry's published rules, its actual market and political legitimacy are different facts; none is a substitute for the others.

The label and the business can diverge

Imagine two registries whose labels both come from the same two-letter code list. One expects most registrants to be local and operates under domestic rules. The other advertises worldwide and welcomes anyone prepared to pay. The characters and their place in the DNS root do not, by themselves, tell us which service each registry runs. This is a thought experiment, not a claim about any particular present-day domain.

That gap was the problem John Klensin set out in RFC 3071, published in February 2001 as an Informational memo. He wrote that the Web had made domain names commercially valuable and that some country-code registries were soliciting or accepting customers outside their associated countries. Meanwhile, some domains once called “generic” had shed the narrow purposes their names implied. The old binary no longer described the market.

Klensin proposed three functional categories: genuinely generic domains, usually open to registrations from any source and promoted broadly; purpose-specific domains, restricted by qualifications unrelated to nationality; and country domains intended chiefly to serve people and organizations inside the associated country. The last group would not aggressively market abroad or rely on substantial foreign fee revenue. All domains in that third category would be ccTLDs, he wrote, but not all ccTLDs would qualify.

The important move was to make those categories orthogonal to the two-letter naming rule. RFC 3071 favored reserving two-character top-level labels to codes in ISO 3166-1, but that syntax did not settle the operating category. Code-list presence could make a label eligible for a certain kind of namespace. It did not tell us where customers lived, what the registry advertised, which law governed disputes or how consistently published rules were enforced.

That difference changes the evidence an operator or policymaker should request. A root-zone record can show that a delegation exists and identify nameservers and contacts. It cannot establish the registry's commercial constituency. A policy page can disclose intended eligibility and dispute rules; registration data and marketing provide evidence of practice, not proof of fair enforcement. Klensin suggested indicators such as whether a registry actively sought overseas registrations, where most registrants were located, whether its manager had a tangible presence in the jurisdiction, and whether a local court could reach registrants.

He also argued that registrants should see material rules before choosing a domain.

RFC 3071 was a proposal and an individual reflection, not a binding classification system. Its taxonomy should not be mistaken for an adopted ICANN rule, nor should any present-day registry be placed in a box from its label alone. The memo's institutional limit is just as important: technical coordination of a root delegation did not make IANA or ICANN competent to decide countryhood, authenticate rival governments or resolve domestic political disputes. Such a move would convert administration into international-relations adjudication.

The historical lesson is therefore not that every ccTLD should be treated like a generic domain. It is that a short identifier, an allocation decision and a service's actual constituency live at different layers. A registry may change its business without changing the characters in the root. A root entry can remain technically valid while telling us little about local consent, law or performance. Analysis should follow the operating evidence—and leave judgments outside the administrator's competence to the institutions that can lawfully make them.

Sources