Summary

  • RFC 2352 proposed a domain path built from a full legal name, legal-form token, locality and country, shifting the first entitlement decision from a DNS registry to company or trademark authorities.
  • The proposal documented a real late-1990s collision between scarce memorable labels and many legitimate names, but a legal-name receipt still did not prove DNS delegation, global identity, operational control or successful service.

A neat answer to the wrong-sized question

The Internet's naming conflict looked deceptively small in 1998. Two businesses wanted the same memorable label. A registry had one slot. Trademark owners, company registrars and domain operators did not share one geography or one test of entitlement. Litigation was growing around a system whose wire protocol knew how to compare labels but not how to decide which claimant deserved them.

RFC 2352 offered an architectural answer. Instead of asking a generic top-level domain to choose one winner for a short name, it proposed putting a legal organisation into a path that already carried jurisdictional context. A British limited company might live below LTD.UK; a French trademark below TM.FR; an American corporation could add a state layer. The general form was a legal-form token, one or more locality identifiers and an ISO country code.

The organisation's label would come from its full registered name. The legal suffix would be omitted because the parent branch already supplied it. Spaces would become hyphens; other punctuation could disappear or become hyphens. A company-name or trademark authority would determine the underlying legal right, and the relevant DNS registry would create the corresponding entry.

That scheme was more disciplined than first-come mythology. It recognised that identical words can belong to different lawful organisations when the jurisdiction or legal form differs. It also recognised that a DNS registry should not improvise company law.

But it answered a bounded question—who holds this name in this legal register—and treated the answer as if it could settle a larger one: what public Internet name should people use?

Uniqueness had a jurisdiction

RFC 2352 said disputes could not arise because legal names were unique within their context. The final phrase carried almost all the weight.

A company name can be unique inside one register while another jurisdiction records the same words. A trademark can be bounded by class, territory, owner and time. A legal suffix can distinguish entities in one system but have no exact counterpart in another. The proposal did not create one worldwide company register. It assembled a DNS path from several institutions whose records had different scopes.

Its normalisation rule introduced another boundary. Replacing spaces and punctuation makes a string usable as a label, but the operation may remove distinctions that a legal record preserves. The resulting domain can point back to evidence; it is not the evidence itself. The legal record, transformation rule, parent delegation and live zone each need a separate receipt.

DNS uses the word authority in a narrower sense. RFC 1034 calls a server authoritative when it has complete information for a zone. That server can answer for the delegated branch. It does not thereby become authoritative about corporate identity, trademark priority or who controls a business.

The distinction matters because a successful lookup is even narrower. It can return resource records associated with an exact name. It does not prove that the organisation still exists, that the registrant controls it lawfully, that a website is secure, or that a user reached the intended service.

The RFC carried its own objection

RFC 2352 was not an IETF standard. It was an independent Informational submission that replaced the earlier RFC 2240. The RFC Editor attached a note that did more than add caution around the edges.

The note observed that the proposal appeared to depend on established organisations abandoning familiar generic names for longer handles without receiving an incentive. Its examples made the continuity cost concrete: a short, remembered name could become a legal-name-and-locality path. It also identified an institutional contradiction. The document treated national namespace structure as a matter within national purview while prescribing how those national structures should encode legal forms and localities.

The editor concluded that implementation might not be politically feasible.

That was not a complaint about label length alone. It exposed two control surfaces. One was the legal register that established a name in a jurisdiction. The other was the DNS hierarchy whose managers decided which branches existed and how delegation worked. The proposal linked them, but linking did not merge their authority.

RFC 920 had already described domains as administrative entities. It also warned that changing a host's domain made old references stale in address tables, mailing lists, old messages, printed directories and human memory. A renamed domain was not merely a cleaner database row. It transferred migration cost to every dependency that had learned the earlier name.

The cost explains why an optional legally grounded address could coexist with a generic name yet struggle to replace it. Public identity accumulates through use. A new legal receipt does not automatically carry the old name's links, correspondence, reputation or recognition.

Later systems separated representation from adjudication

The years after RFC 2352 did not make its underlying conflicts disappear. They produced different mechanisms for different layers.

ICANN adopted the Uniform Domain Name Dispute Resolution Policy in 1999. Its test requires a complainant to establish confusing similarity to a mark, the registrant's lack of rights or legitimate interests, and bad-faith registration and use. That is an adjudicative path attached to registration agreements. It does not derive every domain from a company register, and it does not make every legal name an automatic DNS delegation.

Internationalised domain names addressed a different limit. RFC 2352 noted that the available label representation constrained names written outside ASCII. RFC 3490 later used an ASCII-compatible form at the application boundary so existing DNS infrastructure could carry internationalised labels. Yet it preserved exact-match lookup and explicitly left many linguistic, visual and aural equivalence problems outside the protocol.

Encoding solved representation. It did not decide entitlement.

This separation is the durable lesson. Legal registration, trademark rights, DNS delegation, label encoding, resolver answers, operational control and user recognition can support one another. None can silently stand in for all the others.

A proposal can be valuable without becoming the system

RFC 2352 matters because its failure mode is legible. It found a real mismatch between globally visible short labels and plural legal realities. It tried to preserve context by using a hierarchy instead of forcing every claimant into one flat contest. It also made the registry's evidence problem explicit: an application should contain sufficient proof of legal rights.

But the common technical layer did not need to encode every corporate form and locality to remain useful. DNS needed unique labels within each delegated branch, accurate parent-child delegation and interoperable lookup. Company law needed accountable records inside its jurisdiction. Trademark disputes needed their own tests and forums. Public identity needed continuity that no one database could manufacture.

The historical value is therefore not a verdict that flat names were correct and legal names were wrong. It is evidence that a naming system becomes overextended when it treats one kind of truth as a complete identity system.

RFC 2352 tried to let the legal ledger settle the DNS name. Its own publication record showed why the boundary stayed put.

Sources and limits

The proposal and the RFC Editor's warning are in the RFC 2352 publication record and RFC 2352 text. Its predecessor is RFC 2240. The earlier administrative and technical DNS boundaries come from RFC 920, RFC 1034, RFC 1035 and RFC 1591. The later dispute and representation mechanisms are the ICANN UDRP and RFC 3490. The separation of registry record, operational fact and authority follows Heng Lu's essays on reality layers and minimum common specification with local decision. These sources do not prove adoption of RFC 2352, current ownership of any example name or present legal entitlement in any jurisdiction.