Кратко

  • Предложение ARIN 2013.2 касалось букв с диакритикой в поле имени клиента. ARIN связала решение с новым стандартом вместо Whois; в текущем списке предложение остаётся «On hold».
  • ARIN эксплуатировала RDAP уже в 2015 году и в 2025 году описывала его как основанный на UTF-8. Актуальная документация Reg-RWS ограничивает XML-данные набором ASCII, кроме отдельных свободных комментариев.

Срок ожидания длиной в тринадцать лет

Thomas St.Pierre в заявке от 14 февраля 2013 года перечислил допустимые тогда символы поля «Customer name»: латинские буквы без диакритики, цифры и немного пунктуации. Он просил разрешить буквы, обычные для других языков. Срок обозначил как «Immediate». Запрос был конкретным: сохранять название, а не подгонять его под старую таблицу символов.

Ответ ARIN от 26 февраля разделил регистрацию и поиск. Первую международную обработку реестр счёл несложной, а вторую — зависимой от старого Whois, рассчитанного на ASCII. В рабочей группе WEIRDS IETF готовился преемник. Когда появится разумный стандарт, ARIN вернётся к вопросу. На публичной карточке остались эта дата последнего обновления и статус «On hold».

Преемник появился. Собственный обзор ARIN за июнь 2015 года сообщает, что RFC для RDAP опубликованы в марте и что ARIN уже предоставляет RDAP-каталог и службу перенаправления запросов. В презентации 2025 года реестр называет старый Whois системой без интернационализации, а RDAP — международно поддерживаемым протоколом на базе UTF-8. Текущая инструкция объясняет, как делать такие запросы.

Однако список активных предложений по-прежнему содержит 2013.2 с примечанием о зависимости от стандартизации IETF и совместимости с Whois. Публичная карточка не показывает, какое решение о поле имени приняла ARIN после появления стандарта.

Прочитать запись — ещё не создать её

RDAP отвечает на запросы к каталогу. Новые сведения вводятся через другие инструменты. В документации Reg-RWS сказано, что XML-пакеты поддерживают только ASCII. Для некоторых свободных комментариев сделано узкое исключение: буквы с диакритикой в UTF-8. Поле customerName в пакете клиента отдельно; такого исключения для него инструкция не описывает.

Актуальная проверка авторизованной отправки имени с диакритикой через интерфейсы ARIN или официальная таблица поддерживаемых символов по полям установила бы реальное поведение сервиса. Пока открытые документы фиксируют более узкий факт: современный канал чтения поддерживает UTF-8, опубликованный канал записи описан как ASCII, а старая заявка всё ещё ссылается на ожидаемый стандарт.