Summary

  • RFC 3743 made selected CJK character variants an administrative package: one holder could control a family of related labels, even when only some were active in the zone.
  • A Language Variant Table generated candidates; preferred variants were normally activated, while character variants were normally reserved. The RFC supplied a mechanism, not a universal linguistic judgment or proof of deployment.

The domain name that was larger than its DNS record

An ASCII lookup can make domain registration look like a one-string transaction: a label is available, an applicant registers it, and a zone publishes it. Internationalized labels complicated that picture. In Chinese, Japanese and Korean writing, different code points can look alike, carry related meanings, or represent forms treated as variants in a particular language or region. The DNS protocol can compare encoded labels. It cannot decide, by itself, when two Unicode forms should belong to the same registrant.

That gap was the problem the Joint Engineering Team (JET) addressed in RFC 3743, published in April 2004 as an Informational document. Its contributors came from the Chinese, Taiwanese, Korean and Japanese network-information communities, among others. The IESG note praised the effort to connect policy to an enforcement mechanism, but was equally explicit that the IETF did not dictate a zone’s policy. The same table format could support different local choices.

This is not the same problem as converting a Unicode label into the ASCII-compatible form used in DNS. The earlier IDNA documents standardized preparation and encoding; RFC 3743 addressed how a zone might administer potentially confusing variants once it accepts a label. A protocol can tell an application whether a string passes a technical profile. It cannot settle every language community’s view of equivalence.

A table turns language policy into a registration workflow

The mechanism starts with a Language Variant Table (LVT) for each language a zone supports. For each permitted code point, the table identifies a valid code point, possible preferred variants, and character variants. The labels “preferred” and “character” describe different administrative treatment, not a universal ranking of scripts or a claim that every generated string is a meaningful word.

During registration, the proposed label is first processed under the IDNA-era Nameprep rules. The registry checks it against the valid-code-point table for every language associated with the request. It then generates combinations of preferred and character variants, removes duplicates, and checks candidates against existing registrations and reservations. Zone-specific filtering can exclude forms the table would otherwise produce. These are not automatic outcomes of Unicode; the table and local procedure supply the policy inputs.

The distinction between activation and reservation is the important part. The original label and the eligible preferred variants normally form the set of Zone Variants that are activated in the zone file. Character variants are ordinarily reserved, so another applicant cannot register them, but they are not necessarily published as active labels. RFC 3743 calls the original label, associated language set, activated zone variants and reserved variants an “IDL Package.”

The package changes the unit of administration. Traditional domain processes register, delete or transfer one label at a time. Under this model, the package is atomic: transfer or deletion of the registered label affects its associated variants as a whole. The rule prevents two holders from acquiring forms the zone has decided to treat as related. It also means the registrant’s transaction can include labels that never appear as active DNS names.

The RFC’s worked examples show why language association matters. A label can be acceptable under several language tables, produce different preferred forms across those tables, or fail because a code point is not valid for one selected language. The examples are algorithm illustrations, not evidence that a named registry adopted a specific table or that a particular commercial domain was actually registered under the package model.

What the package cannot prove

RFC 3743 deliberately leaves important choices outside the mechanism. Each zone determines its tables, language associations, conflict policy, acceptable number of generated variants, and division of work between registrar and registry. The RFC assumes first-come, first-served in examples but allows a zone to substitute its own rights or dispute rules. It does not identify who has legal rights to a string, prove that a package was activated, show that an A-label was inserted in a zone, or demonstrate that a query resolves.

Later IDNA2008 documents provide a useful boundary. They specify technical validity and registration/lookup behavior, while recognizing that registries may add local restrictions. That continuity does not make RFC 3743’s IDNA2003-era algorithms current protocol rules. Nor does the later protocol retroactively turn the JET table into a universal language standard. Validation, registry policy, registration, zone publication and successful resolution remain different receipts.

The historical contribution is therefore administrative architecture. JET did not try to encode every CJK equivalence judgment into DNS. It gave zone operators a way to express local variant choices and bind related labels to one package owner. That reduced one class of split-registration risk by introducing another dependency: a zone’s language tables and lifecycle rules became part of what an applicant was actually receiving. The visible domain could be one label; the reserved object could be much larger.

Sources