Summary

  • ICANN’s 24 August 2026 Public Comment summary records one correction to the draft Javanese Reference Label Generation Rules: U+A9B4 should be allowed after U+A9BA or U+A9BB, not U+A9BA or U+A9BC.
  • The reported expression is not confined to explanatory prose. It appears in the 23 April supporting proposal, the human-readable HTML and the RFC 7940 XML rule named follows-A9BA-A9BC.
  • ICANN says the update will be discussed with the Javanese community and then incorporated into the final version. As of 1 September, ICANN’s publication page still listed 25 October 2024 as current and contained no final Javanese XML/HTML pair.
  • A Reference LGR guides registry-table design and ICANN review; it is not itself a registry operator’s IDN table. Publication and downstream adoption therefore need separate evidence.
  • A versioned correction receipt should join the submission, community disposition, exact rule diff and final artifact hashes without claiming that a summary report changed live DNS behavior.

The error is present in all three draft views

The Public Comment proceeding opened on 12 May and closed on 23 June. It covered two new Reference LGRs, for Javanese and Unified Canadian Aboriginal Syllabics, plus six updates to existing rulesets. ICANN counted 33 relevant comments. Thirty-two supported the package; one concentrated on the Javanese correction and on clarifying how two rules interact.

That ratio can make the single correction sound editorially small. Technically, it is exact. U+A9B4 is JAVANESE VOWEL SIGN TARUNG. The April proposal says it may follow U+A9BA, JAVANESE VOWEL SIGN TALING, or U+A9BC, JAVANESE VOWEL SIGN PEPET, and may not follow other dependent vowels. Arif Budiarto, identifying himself as a contributor to the proposal, says the second predecessor is wrong. The intended partner is U+A9BB, JAVANESE VOWEL SIGN DIRGA MURE.

The distinction matters because the same expression is carried by three connected artifacts. Page 38 of the supporting proposal gives it as Rule 4. The readable HTML renders a rule called follows-A9BA-A9BC. Most importantly, the XML assigns that rule to U+A9B4 and defines its class as A9BA and A9BC. The public comment therefore identifies a change to the machine-readable condition, not only a typo in a narrative caption.

The submission also resolves an apparent scope question. Rule 3 is the general rule: a dependent vowel must follow a consonant, a medial consonant or an independent vowel. Rule 4 is more specific: it further limits U+A9B4 to the permitted preceding dependent vowels. The Working Group said it would update the relevant text, corresponding rule references and the supporting document so the special restriction is not mistaken for an exception that the general rule somehow erases.

None of this means U+A9BC is generally invalid. It remains in the draft repertoire as JAVANESE VOWEL SIGN PEPET. The correction concerns one relation: whether U+A9B4 may follow it. Precision here prevents a bounded rule change from being inflated into a claim about the character as a whole.

The summary records a disposition, not a final ruleset

ICANN’s summary does more than repeat the submission. It says the feedback will be discussed with the Javanese community and then incorporated into the final version. Its next-step section says that, after considering comments and modifying the package as needed, final Reference LGRs will be posted on the Second-Level Reference LGR page.

Those sentences create a sequence with at least four states: a public draft; a submitted correction; community discussion and ICANN disposition; and a final published package. On 1 September, the public sequence had reached the third state. The publication page still called 25 October 2024 its current version and listed no Javanese script entry. No final Javanese XML, matching HTML or revised supporting proposal appeared in that list.

“Pending” is not a criticism of the interval. Eight days is a short time for community confirmation, editorial changes, machine-readable review and coordinated publication across several documents. Nor does the summary suggest resistance: it expressly says the update will be incorporated after discussion. The problem is categorical, not temporal. A reader should not treat the summary PDF as though it were the corrected RFC 7940 artifact.

ICANN’s own development guidelines make that boundary important. Reference LGRs are specified in XML, while explanatory notes and review history may accompany the XML. The review questions include whether the XML accurately represents the desired code points and rules. A prose assurance can establish intent; only the final versioned files can show that the intent was represented consistently in the ruleset that ICANN publishes for operational reference.

Reference, review and adoption are different events

The Second-Level Reference LGR page describes what happens after publication. Registry operators may use the reference rules while designing their Internationalized Domain Name tables. ICANN uses the Reference LGRs when reviewing IDN tables that gTLD registries submit.

That is a strong operational role, but not automatic deployment. The common Reference LGR is one artifact. A registry’s submitted table is another. ICANN’s review is a third event, and the operator’s implementation state is a fourth. A corrected reference can guide all three without silently rewriting any of them.

This separation protects the reporting in both directions. It prevents a draft correction from being described as a live-domain incident when no affected registry table, rejected registration or broken label has been identified. It also prevents a final publication from being celebrated as universal remediation when no downstream table has yet been inspected.

The most useful question after publication will therefore not be merely “Is the final Javanese XML online?” It will be “Which version did each later registry-table submission cite, what did ICANN review, and what did the operator adopt?” The answers may arrive at different times and should remain separately attributable.

The correction needs a compact, versioned receipt

ICANN already exposes most ingredients of such a record: proceeding, submission, summary, draft XML, HTML, supporting proposal and publication index. What is missing is one joined state transition.

A correction receipt should first bind the observation. It would name the 23 April package and preserve hashes for its XML, HTML and supporting PDF. It would identify U+A9B4, the affected rule identifier, the draft A9BA/A9BC expression and the submission that requested A9BA/A9BB instead. The submitter’s bounded explanation should be retained: Rule 4 is the specific condition; the change restores intended orthography rather than inventing a new one.

The second part should record authority and process. It would show the submission time, community-discussion status, ICANN disposition, any accepted wording change and the person or accountable function that marked the package ready for final publication. If the final implementation renames the rule or restructures the XML instead of making a literal token substitution, the receipt would explain the equivalent result.

The third part should bind publication. Final XML, HTML and supporting-document URLs, version, timestamp and hashes belong together. A small machine-readable diff should demonstrate the removal of A9BC and insertion of A9BB in the U+A9B4 context. Conformance examples should show the intended allowed and disallowed sequences. The old draft should remain reachable but visibly superseded, so a cached link cannot masquerade as current.

Finally, downstream links should be separate. A registry-table submission can cite the Reference LGR version it used; ICANN can record the review result; the operator can record adoption. Absence of those links means “not yet evidenced,” not “not adopted.”

This is the minimum-specification discipline in Heng Lu’s model. The common layer carries the deterministic facts that other actors need—artifact, actor, rule, state, version, date and revision—while localized decisions stay with their accountable operators. The record is small precisely because it refuses to manufacture deployment from intent.

What the evidence does not establish

No reviewed source identifies a current gTLD registry table that copied the April Javanese draft. No active domain, failed registration, security incident or user harm has been connected to the A9BC expression. The draft package was offered for Public Comment, which is a stage designed to expose and correct problems before finalization.

The evidence also does not show that ICANN rejected the correction. The summary accepts the need for an update, retains community discussion and promises final incorporation. Calling the correction “ignored” would contradict the public record.

Nor should the source be reduced to one mistaken character. The proceeding added two new script references and updated six others; the Javanese package represents substantial language-community work. The governance value of the correction is that the process surfaced a precise inconsistency before the final publication. The remaining obligation is to make closure just as inspectable as discovery.

Sources

  1. ICANN — Public Comment Summary Report, 24 August 2026
  2. ICANN — Additional Reference Label Generation Rules and Related Updates
  3. ICANN Public Comment — submission by Arif Budiarto
  4. ICANN — 12 May 2026 Reference LGR package index
  5. ICANN — draft Javanese Reference LGR, XML
  6. ICANN — draft Javanese Reference LGR, HTML
  7. Javanese Generation Panel — supporting proposal
  8. ICANN — Second-Level Reference Label Generation Rules
  9. ICANN — Guidelines for Developing Reference LGRs for the Second Level
  10. RFC Editor — RFC 7940
  11. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption