Single-Character Runic Internationalized Domain Names

Report status and use

The raw source is retained in protected governed memory as a research input. This public page is the active corrected synthesis. It does not promote every source statement into project doctrine and does not expose the protected raw report.

Source status: K08 governed research input; technical, historical, legal, security, and performance propositions require explicit source or empirical validation.. Public correction state: K08 CORRECTED PUBLIC SYNTHESIS; RAW SOURCE RETAINED.

Direct findings

1. The report distinguishes Unicode validity, IDNA validity, registry permission, registrar support, registration, delegation, DNS resolution, and hosted service operation.
2. A U-label is human-readable Unicode while an A-label is its ASCII-compatible IDNA representation.
3. Punycode is an encoding mechanism, not a registration right or security guarantee.
4. IDNA processing occurs in applications and does not require changing the DNS protocol itself.
5. Registry and registrar policy can reject a technically encodable label.
6. A registered name may still be undelegated, non-resolving, misconfigured, uncertificated, or not hosting a site.
7. Browser display can fall back to A-labels because of script and confusability policy.
8. TLS, DNSSEC, RDAP, SMTPUTF8, and email-address internationalization have separate operational requirements.
9. K08 preserves all owner-required Runic U-labels and their verified ACE mappings in static navigation records.
10. The active synthesis avoids claiming that a code point or Punycode conversion proves live ownership, delegation, or service availability.

Claim-status breakdown

Analytical scope preserved from the source

• The Architecture and History of Single-Character Anglo-Saxon Fuþorc Internationalized Domain Names
• The Genesis of the Domain Name System and the Ascendancy of ASCII
• The Internationalized Domain Name Framework
• The IDNA2003 Standard and Character Mapping
• The IDNA2008 Revision and Property-Based Inclusion
• U-Labels, A-Labels, and the Bootstring Algorithm
• The Mathematical Mechanics of Punycode (RFC 3492\)
• The Anglo-Saxon Fuþorc in Historical and Technical Context
• Fuþorc-Only Explanatory Prose
• The Eight Distinct States of Domain Name Viability
• 1\. Unicode-Valid
• 2\. IDNA-Valid

The public synthesis preserves these areas as a map of the source’s reasoning. Inclusion in this list does not mean each heading is accepted as current law, verified implementation, or project doctrine.

Implementation implications

• Create canonical records with stable IDs, claim status, sources, currentness, and correction state.
• Separate legal authority from technical control and source authenticity.
• Require operational evidence for claims of deployment or current operation.
• Preserve review, challenge, appeal, and correction paths.
• Use the appropriate ecosystem authority for governance, registry, assurance, or capital functions.

Contradictions and limitations

The supplied source may contain forward-looking proposals, legal generalizations, implementation assumptions, or institution-role language that requires correction. The active synthesis therefore preserves uncertainty, labels proposals, and rejects any implication that a report, hash, signature, or website creates legal personhood, citizenship, sovereignty, factual truth, deployment, or authority.

External standards and law can change after the research cutoff. Source validity and currency must be rechecked before high-stakes reliance.

Source provenance

Correction history

Initial correction review created the public synthesis, preserved the raw source separately, enforced ecosystem-role boundaries, removed unsupported authority implications, and applied the project’s claim-status vocabulary. No later public correction is recorded in this release.

Related knowledge

Runic Digital Infrastructure owns this report’s topic classification.

• Does a Punycode label prove that a domain is live?
• How should Runic pages be made discoverable?
• Why must IDN lifecycle states remain separate?
• How are unsupported history events quarantined?
• Can a history event be promoted by a signature alone?
• What does an IDN observation diff prove?
• Does an evidence-acquisition docket verify history?
• What does a signed domain observation chain prove?

Governed report-finding claims

Each proposition has a stable ID, status, scope, owning route, evidence relationship, currentness qualification, correction state, and synchronized JSON record. Record completeness does not make the proposition true.