1. Introduction
RFC 1591 [1] has been heavily discussed and referenced in the last year or two, especially in discussions within ICANN and its predecessors about the creation, delegation, and management of top- level domains. In particular, the ICANN Domain Name Supporting Organization (DNSO), and especially its ccTLD constituency, have been the home of many discussions in which 1591 and interpretations of it have been cited in support of a variety of sometimes-contradictory positions. During that period, other discussions have gone on to try to reconstruct the thinking that went into RFC 1591. Those in turn have led me and others to muse on how that original thinking might relate to some of the issues being raised. 1591 is, I believe, one of Jon Postel's masterpieces, drawing together very different philosophies (e.g., his traditional view that people are basically reasonable and will do the right thing if told what it is with some stronger mechanisms when that model is not successful) into a single whole.
RFC 1591 was written in the context of the assumption that what it described as generic TLDs would be bound to policies and categories of registration (see the "This domain is intended..." text in section 2) while ccTLDs were expected to be used primarily to support users and uses within and for a country and its residents. The notion that different domains would be run in different ways --albeit within the broad contexts of "public service on behalf of the Internet community" and "trustee... for the global Internet community"-- was considered a design feature and a safeguard against a variety of potential abuses. Obviously the world has changed in many ways in the seven or eight years since 1591 was written. In particular, the Internet has become more heavily used and, because the design of the world wide web has put domain names in front of users, top-level domain names and registrations in them have been heavily in demand: not only has the number of hosts increased dramatically during that time, but the ratio between registered domain names and physical hosts has increased very significantly.
The issues 1591 attempted to address when it was written and those we face today have not changed significantly in principle. But one alternative to present trends would be to take a step back to refine it into a model that can function effectively today. Therefore, it may be useful to try to reconstruct 1591's principles and think about their applicability today as a model that could continue to be applied: not because it is historically significant, but because many of its elements have proven to work reasonably well, even in difficult situations. In particular, for many domains (some in 1591's "generic" list and others in its "country code" category) the notion of "public service" --expected then to imply being carried out at no or minimal cost to the users, not merely on a non-profit basis-- has yielded to profitability calculations. And, in most of the rest, considerations of at least calculating and recovering costs have crept in. While many of us feel some nostalgia for the old system, it is clear that its days are waning if not gone: perhaps the public service notions as understood when 1591 was written just don't scale to rapid internet growth and very large numbers of yregistrations.
In particular, some ccTLDs have advertised for registrations outside the designated countries (or other entities), while others have made clear decisions to allow registrations by non-nationals. These decisions and others have produced protests from many sides, suggesting, in turn, that a recategorization is in order. For example, we have heard concerns by governments and managers of traditional, "public service", in-country, ccTLDs about excessive ICANN interference and fears of being forced to conform to internationally-set policies for dispute resolution when their domestic ones are considered more appropriate. We have also heard concerns from registrars and operators of externally-marketed ccTLDs about unreasonable government interference and from gTLD registrars and registries about unreasonable competition from aggressively marketed ccTLDs. The appropriate distinction is no longer between what RFC 1591 described as "generic" TLDs (but which were really intended to be "purpose-specific", a term I will use again below) and ccTLDs but among:
(i) true "generic" TLDs, in which any registration is acceptable
and, ordinarily, registrations from all sources are actively
promoted. This list currently includes (the formerly purpose-
specific) COM, NET, and ORG, and some ccTLDs. There have been
proposals from time to time for additional TLDs of this variety in
which, as with COM (and, more recently, NET and ORG) anyone
(generally subject only to name conflicts and national law) could
register who could pay the fees.
(ii) purpose-specific TLDs, in which registration is accepted only
from organizations or individuals meeting particular
qualifications, but where those qualifications are not tied to
national boundaries. This list currently includes INT, EDU, the
infrastructure domain ARPA, and, arguably, the specialized US
Government TLDs MIL and GOV. There have been proposals from time
to time for other international TLDs of this variety, e.g., for
medical entities such as physicians and hospitals and for museums.
ICANN has recently approved several TLDs of this type and
describes them as "sponsored" TLDs.
(iii) Country domains, operated according to the original
underlying assumptions of 1591, i.e., registrants are largely
expected to be people or other entities within the country. While
external registrations might be accepted by some of these, the
country does not aggressively advertise for such registrations,
nor does anyone expect to derive significant fee revenue from
them. All current domains in this category are ccTLDs, but not
all ccTLDs are in this category.
These categories are clearly orthogonal to the association between the use of the IS 3166-1 registered code list [2] and two-letter "country" domain names. If that relationship is to be maintained (and I believe it is desirable), the only inherent requirement is that no two-letter TLDs be created except from that list (in order to avoid future conflicts). ICANN should control the allocation and delegation of TLDs using these, and other, criteria, but only registered 3166-1 two letter codes should be used as two-letter TLDs.
