Кратко

  • ICANN применяет два разных контроля: строки ASCII из одной или двух букв не допускаются уже при подаче; запрошенная двухсимвольная строка или один из её вариантов может быть остановлена позднее, если панель сочтёт её визуально сходной с двухсимвольной строкой ASCII либо её вариантом.
  • Инструмент SSE выполняет предварительный отбор, но окончательное решение принимает панель. Проверяемый результат должен раскрывать решающую пару меток, письменность и регистр, пропущенные сравнения, мотивировку панели и 21-дневный срок оспаривания.

Самый сложный случай — не попытка напрямую ввести две латинские буквы ASCII. Такой ввод относится к первой линии контроля и должен блокироваться системой подачи. Трудность возникает, когда заявитель выбирает два символа иной письменности, выполняет применимые требования IDN и правил генерации меток корневой зоны и буквально не подаёт никакого двухбуквенного кода страны.

Applicant Guidebook для раунда 2026 года устанавливает вторую линию. В String Similarity Evaluation основная строка и её варианты сравниваются с набором, включающим все двухсимвольные строки ASCII и их варианты. Если запрошенная двухсимвольная строка или любой её вариант признаётся сходным с элементом этой категории, заявка не продвигается дальше.

Два контроля нельзя скрывать под общим выражением «заблокированное имя». Первый проверяет идентичность и допустимость. Второй требует суждения о визуальном сходстве разных меток. Поэтому им соответствуют разные доказательства, ошибки и основания для оспаривания.

Первая линия — прямое сопоставление

Раздел 7.2.1 Guidebook относит все прочие строки ASCII из одной или двух букв к недопустимым для подачи. Текущая FAQ ICANN называет ту же категорию. Раздел 7.2.1.1 описывает автоматическую проверку: если выбранная строка входит в применимый блокирующий список, система не позволяет продолжить с ней и требует выбрать другую.

Для такого решения достаточно короткой записи: введённое значение, нормализованная форма, совпавшая категория, версия списка и время проверки. Здесь не требуется оценивать шрифт или восприятие — нужно объяснить точное попадание в запрещённый набор.

Во второй линии вопрос иной. Не-ASCII-метка может не совпадать ни с одной двухсимвольной строкой ASCII и всё же быть признана визуально сходной с ней или её вариантом в String Similarity Evaluation. Решающее отношение может создать вариант, а не основная строка.

Уведомление должно сразу указывать, какой контроль сработал. Иначе заявитель не понимает, что проверять: нормализацию, категорию списка, вариантную связь, отображение или вывод панели.

Решающий переход может проходить через вариант

Область SSE не ограничена основной строкой. Раздел 7.10.1 включает основную метку, распределяемые варианты и, в установленных пределах, блокируемые варианты. Для рассматриваемого здесь отношения замороженный пакет фактов подтверждает сравнение со всеми двухсимвольными строками ASCII и их вариантами.

Определяющая связь может быть основной-основной, основной-вариант, вариант-основной или вариант-вариант. Кроме того, раздел 7.10.3 предписывает всем членам одного variant-string-set разделять общий результат SSE. Одна установленная связь способна распространить последствие на весь набор меток заявки.

Фраза «сходна с двухсимвольной строкой ASCII» поэтому недостаточна. В результате следует указать:

  1. точную пару основных меток или вариантов;
  2. A-label, U-label и кодовые точки Unicode обеих сторон;
  3. письменность, регистр и вариантное отношение;
  4. категорию сходства и применённое руководство; и
  5. членов вариантного набора, наследующих результат.

Это редакционная рекомендация для реконструируемой записи, а не описание полей, которые ICANN действительно опубликует. Пакет не устанавливает формат индивидуального результата раунда 2026 года.

Данные SSE от июля 2026 года показывают недостаточность простого подсчёта знаков

23 июля 2026 года ICANN опубликовала версию 1.0 SSE Data и SSE Guidelines. Эксперты сравнивали элементы внутри письменности, между связанными письменностями и с символами ASCII в верхнем и нижнем регистре. В данные включены отношения вариантов RZ-LGR, чтобы инструмент мог строить потенциальные множества сходства.

В части об ASCII официальный документ приводит, среди прочего, отношения i и l, m и rn, n и ri, vv и w. Их сила различается. Некоторые пары классифицированы экспертами непосредственно; другие входят в множества через интеграцию вариантов или транзитивность. Переход к верхнему регистру тоже способен обнаружить сходство, менее заметное в нижнем.

Это методические примеры, а не реальные заявки раунда 2026 года. Фактический пакет статьи не содержит индивидуального результата SSE, статистики ложных срабатываний, частоты оспариваний или отмен. Нельзя превращать пример из технической документации в утверждение о состоявшемся отказе конкретному заявителю.

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

Инструмент отбирает кандидатов, панель отвечает за решение

SSE Guidelines от июля 2026 года отводят инструменту роль предварительного фильтра. Он формирует потенциальные множества и отчёт. Панель может добавлять, изменять или удалять множества, но должна обосновывать действия. Если строка отсутствует в отчёте, это не означает автоматическое прохождение: её и варианты необходимо проверить вручную.

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

Публичная запись должна связать две стадии: обнаружил ли инструмент пару, какую категорию предложил, к какому выводу пришла панель и почему она отклонилась от предложения, если отклонилась. Балл без лежащей под ним пары — не мотивировка. Человеческий вывод без ссылки на применённое руководство также нельзя проверить.

Guidelines разрешают не выполнять отдельные сравнения блокируемых вариантов, когда смешение письменностей явно маловероятно. Это экономит бесполезную работу, но пропуск сам является решением. Запись должна называть пропущенное сравнение, критерий и того, кто его одобрил.

Два отношения дают два последствия внутри одной категории

Таблица 7-5 различает последствия. Если запрошенная строка совпадает с двухсимвольной строкой ASCII или является её вариантом, заявка не принимается. Если строка визуально сходна, но вариантом не является, она не может продолжаться.

Различие следует фиксировать отдельно, поскольку совпадение или формальное отношение варианта — не тот же вывод, что визуальное сходство, хотя оба останавливают заявку в этой категории. Глоссарий ICANN описывает категорию как пространство потенциальных будущих ccTLD; замороженный пакет не выводит отсюда иной процедуры.

Такое описание программы не устанавливает собственность. Источники не доказывают, что ICANN, ISO 3166 Maintenance Agency или государство владеют двухбуквенным кодом как имуществом. Guidebook задаёт правило gTLD-процесса, но не разрешает все вопросы суверенитета или имущественных прав на идентификаторы.

Двадцать один день требуют пригодного к использованию решения с первого дня

Заявитель может оспорить результат SSE в течение 21 дня после получения, ссылаясь на фактическую, процедурную или системную ошибку. Подтверждённая ошибка ведёт к повторной оценке с учётом выводов оспаривания; если ошибка не подтверждена, исходный результат сохраняется.

Короткий срок имеет смысл лишь тогда, когда обоснование приходит вместе с уведомлением. Заявитель не должен тратить дни на выяснение того, какой вариант сработал, какой регистр отображался или добавила ли панель пару, отсутствовавшую в предварительном отчёте.

Минимальная запись должна содержать:

  1. сработавший контроль — прямой запрет или оценку сходства;
  2. точную пару основных меток или вариантов;
  3. нормализованные формы, A-label, U-label, кодовые точки, письменности и регистр;
  4. категорию сходства и применённое руководство;
  5. результат предварительного отбора и каждое изменение панели;
  6. пропущенные сравнения с обоснованием низкой смешиваемости;
  7. последствие для всего variant-string-set; и
  8. время уведомления, срок оспаривания и стабильный идентификатор результата.

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

Двухсимвольный ASCII-барьер может защищать понятную границу корня DNS и не быть чёрным ящиком. Для этого запись должна сохранять различие: короткая ASCII-строка может блокироваться при подаче; другая двухсимвольная метка или её вариант — исключаться позднее на основе мотивированной визуальной оценки. Публикация сработавшей линии и решающей пары позволяет проверять правило, не превращая инструмент в судью.

Источники