Кратко

  • В отчёте ICANN от 24 августа 2026 года сказано, что U+A9B4 может следовать за U+A9BA или U+A9BB, а не за U+A9BA или U+A9BC, как записано в проекте.
  • Ошибка присутствует в пояснительном предложении, HTML и XML от 23 апреля. В XML применённое к U+A9B4 правило называется follows-A9BA-A9BC.
  • ICANN намерена обсудить изменение с яванским сообществом и внести его в финальную версию. На 1 сентября страница публикаций всё ещё считала текущей версию от 25 октября 2024 года и не содержала окончательного яванского LGR.
  • Эталонный LGR помогает операторам проектировать IDN-таблицы и ICANN — проверять их, но не является таблицей конкретного реестра и не доказывает внедрение.
  • Версионная квитанция должна связать замечание, решение сообщества, точную разницу и хэши финальных файлов, оставив принятие каждым реестром отдельным состоянием.

Ошибка дошла до машиночитаемого правила

Обсуждение началось 12 мая и завершилось 23 июня. ICANN вынесла на него два новых эталонных LGR — для яванского письма и UCAS — и шесть обновлений. Из 33 релевантных комментариев 32 поддержали пакет, а один сосредоточился на исправлении и связи двух яванских правил.

Arif Budiarto, участник подготовки предложения, указал: U+A9B4, JAVANESE VOWEL SIGN TARUNG, может следовать за U+A9BA, JAVANESE VOWEL SIGN TALING, либо U+A9BB, JAVANESE VOWEL SIGN DIRGA MURE. В проекте вместо U+A9BB фигурировал U+A9BC, JAVANESE VOWEL SIGN PEPET. По словам автора замечания, исправление не меняет орфографический замысел, а точно его восстанавливает.

Формула A9BA/A9BC встречается на странице 38 пояснительного документа в правиле 4. HTML показывает то же. XML назначает U+A9B4 условие follows-A9BA-A9BC, класс которого содержит A9BA и A9BC. Следовательно, редактировать только абзац недостаточно: изменение должно попасть в файл, который обрабатывают инструменты.

Правило 3 задаёт общий порядок для зависимых гласных: после согласной, медиальной согласной или независимой гласной. Правило 4 дополнительно ограничивает именно U+A9B4. Рабочая группа обещала синхронно обновить текст, ссылки на правила и пояснение, чтобы частное ограничение не затерялось в общем.

Сам U+A9BC не объявляется недопустимым символом. Он остаётся в проектном репертуаре. Исправляется только его роль как возможного предшественника U+A9B4 в конкретном условии.

Отчёт фиксирует направление, но не финальные байты

Сводка ICANN даёт определённый ответ: обновление обсудят с яванским сообществом, затем включат в окончательную версию; после рассмотрения комментариев и необходимых правок финальные LGR появятся на странице Second-Level Reference LGR.

Это свидетельство принятого курса и опровержение тезиса, будто замечание проигнорировали. Но это ещё не исправленный XML. При проверке 1 сентября официальная страница называла текущей версию от 25 октября 2024 года, а яванской строки в перечне письменностей не было. Доступным пакетом оставался апрельский проект для обсуждения.

Восьмидневный интервал не означает ненормальной задержки. Согласование с сообществом, правка трёх представлений и валидация XML требуют времени. Существенно не смешивать статусы: «исправление зафиксировано, финальная версия ожидается» точнее, чем «правило уже исправлено» или «исправление отвергнуто».

Руководство ICANN требует представлять правила в XML по RFC 7940 и проверять, верно ли файл характеризует задуманные кодовые точки и условия. Текст отчёта подтверждает намерение; версия и хэш подтверждают результат.

Эталон не равен таблице оператора

Операторы могут опираться на эталонные LGR при проектировании таблиц интернационализированных доменных имён. ICANN использует их при проверке таблиц, которые подают gTLD-реестры. Это практический механизм координации, но не дистанционное обновление конфигураций.

Общий файл, поданная таблица, решение ICANN и реально используемая таблица принадлежат разным субъектам. Из изученных источников нельзя установить, что какой-либо действующий реестр скопировал апрельское условие, что регистрация была отклонена, домен перестал работать или произошёл инцидент. И будущая публикация финального XML сама по себе не докажет всеобщего принятия.

Как должна выглядеть квитанция исправления

Первый блок закрепляет наблюдение: пакет от 23 апреля, URL и хэши XML, HTML и PDF, U+A9B4, идентификатор правила, пара A9BA/A9BC и требование заменить её на A9BA/A9BB. Там же сохраняется соотношение правил 3 и 4.

Второй блок закрепляет полномочия: время комментария, состояние обсуждения с сообществом, решение ICANN и функцию, отвечающую за финальную проверку. Если условие переименуют или перестроят, квитанция покажет семантическую эквивалентность, а не потребует буквальной замены строки.

Третий блок связывает публикацию: версию, дату, ссылки и хэши XML, HTML и пояснительного документа. Машиночитаемая разница показывает удаление A9BC и добавление A9BB в частный контекст U+A9B4; тестовые примеры фиксируют допустимые и недопустимые последовательности. Старый проект сохраняется, но получает явную отметку о замене.

Шаги реестров идут отдельными ссылками: использованная версия, результат проверки ICANN и состояние внедрения. Нет ссылки — значит нет публичного подтверждения, а не обязательно нет внедрения.

В минимальной модели Heng Lu общий слой несёт только субъекта, артефакт, правило, статус, версию, дату и ревизию. Локальное решение остаётся за тем, кто за него отвечает.

Границы вывода

Этот эпизод не доказывает сбой действующего DNS, ущерб пользователям или небрежность ICANN. Публичное обсуждение как раз должно выявлять ошибки до финализации. Отчёт обещает включить исправление, поэтому нет оснований говорить и о его отклонении.

Институциональный тест теперь прост: завершение должно быть столь же проверяемым, как обнаружение, — от решения до финальных файлов.

Источники

  1. ICANN — сводный отчёт, 24 августа 2026 года
  2. ICANN — обсуждение дополнительных эталонных LGR
  3. ICANN — комментарий Arif Budiarto
  4. ICANN — указатель пакета от 12 мая
  5. ICANN — проект яванского LGR в XML
  6. ICANN — проект яванского LGR в HTML
  7. Яванская Generation Panel — пояснительное предложение
  8. ICANN — эталонные LGR второго уровня
  9. ICANN — руководство по разработке
  10. RFC Editor — RFC 7940
  11. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption