Кратко

  • RFC 3743 объединил отдельные варианты китайских, японских и корейских символов в административный пакет, связанный с одним владельцем.
  • Предпочтительные варианты обычно активировались в зоне; остальные варианты, как правило, резервировались, но не становились активными DNS-метками. Документ не доказывает, что конкретный реестр принял таблицу или что доменное имя разрешается.

Объект регистрации шире видимого имени

Регистрация домена часто выглядит как сделка с одной строкой: если она свободна, заявитель её получает, после чего зона может её опубликовать. Интернационализированные имена усложняют эту картину. В китайском, японском и корейском письме разные кодовые точки могут выглядеть одинаково, иметь близкие значения или считаться вариантами в определённом языке и регионе. DNS сравнивает закодированные метки, но сам не решает, должны ли две формы Unicode принадлежать одному владельцу.

Именно этот административный разрыв описан в RFC 3743, информационном документе, опубликованном в апреле 2004 года командой Joint Engineering Team (JET). Среди участников были сетевые информационные сообщества Китая, Тайваня, Кореи и Японии. Примечание IESG приветствовало связь между политикой и механизмом исполнения, но отдельно подчёркивало: IETF не устанавливает политику зон. Один формат таблиц может поддерживать разные локальные решения.

Речь не о преобразовании Unicode-метки в ASCII-совместимую форму для DNS. Предшествующие документы IDNA стандартизировали подготовку и кодирование. RFC 3743 описывает, как зона может администрировать формы, способные вызвать путаницу, после принятия метки: некоторые варианты не должны оказаться у разных владельцев. Технический профиль может проверить допустимость строки, но не может вынести универсальное решение о языковой эквивалентности.

Таблица превращает языковую политику в процедуру регистрации

Для каждого языка, разрешённого в зоне, используется Language Variant Table (LVT). Она указывает допустимые кодовые точки, предпочтительные варианты и варианты символов. Это категории административной обработки, а не универсальная иерархия письменностей и не обещание, что каждая сгенерированная комбинация будет осмысленным словом.

При регистрации предложенная метка сначала проходит Nameprep в соответствии с IDNA того времени. Затем реестр проверяет символы по таблице каждого языка, указанного в заявке. После этого он строит комбинации предпочтительных вариантов и вариантов символов, удаляет дубликаты и сверяет кандидатов с уже зарегистрированными и зарезервированными метками. Зона может дополнительно отфильтровать варианты по своей политике. Unicode не определяет этот результат — его задают таблица и локальная процедура.

Ключевое различие — между активацией и резервированием. Исходная метка и, как правило, допустимые предпочтительные варианты активируются и попадают в файл зоны. Варианты символов обычно резервируются: другой заявитель не может зарегистрировать их, но они не обязательно публикуются как активные DNS-метки. RFC 3743 называет совокупность исходной метки, связанных языков, активных вариантов зоны и резервных вариантов «пакетом IDL».

Пакет меняет единицу администрирования. В традиционной модели метки регистрируют, удаляют и передают по отдельности. Здесь пакет атомарен: передача или удаление IDL затрагивает весь связанный набор вариантов. Это не даёт разным владельцам получить формы, которые зона решила считать родственными, но означает, что сделка может охватывать строки, никогда не появлявшиеся в активном DNS.

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

Чего резервирование не доказывает

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

Позднейшие документы IDNA2008 помогают разграничить слои. Они устанавливают технические требования к допустимости, регистрации и поиску, признавая при этом возможность дополнительных ограничений реестров. Эта преемственность не превращает алгоритмы эпохи IDNA2003 из RFC 3743 в действующие правила протокола и не делает таблицу JET универсальным языковым стандартом. Проверка, политика реестра, регистрация, публикация в зоне и разрешение имени — разные свидетельства.

Исторический вклад JET заключался в административной архитектуре. Команда не пыталась зашить все решения об эквивалентности CJK в протокол DNS. Она дала администраторам зон способ выразить местные правила вариантов и связать родственные формы с одним владельцем. Это снижает риск разделения форм между владельцами, но создаёт другую зависимость: таблица языка и правила жизненного цикла становятся частью приобретаемого объекта. Видимой может быть одна метка, а резервироваться будет гораздо больший набор.

Источники