Кратко

  • В текущей записи AFRINIC о WHOIS 2.10.7 от 29 ноября 2022 года JSContact назван новой функцией RDAP.
  • Текущее руководство RDAP описывает запросы, клиент и перенаправление за пределы региона, но не называет версию JSContact, представление ответа, сигнал соответствия или способ запроса клиента.
  • Это граница публичной документации, а не вывод о поведении endpoint, нарушении стандарта или ущербе.

Запись об изменении и инструкция для читателя — разные записи

Журнал AFRINIC говорит вполне определённо: WHOIS 2.10.7 указан как текущий выпуск. В заметке от 29 ноября 2022 года перечислены исправления и улучшения, связанные с соответствием профилю NRO RDAP, а также новая функция RDAP — JSContact. Из этого следует ровно одно положительное обстоятельство: AFRINIC публично сообщила о функциональном изменении.

Руководство RDAP отвечает на другой вопрос. Оно указывает endpoint, пути запросов по IP-адресу, autnum, обратному DNS и сущности, отсылает к клиенту NicInfo и объясняет HTTP 301 для ресурса, относящегося к другой региональной зоне. Это полезная публичная карта обычного поиска.

Однако нынешнее руководство не связывает эту карту с названием функции из журнала. В его разделе о RDAP нет JSContact, jCard, rdapConformance и version. Поэтому по двум опубликованным страницам нельзя установить, какое представление контактных данных подразумевается, относится ли к нему версия, можно ли запросить иной вариант и какая метка ответа сообщит клиенту о сделанном выборе.

Из этого нельзя делать более широкий вывод. Отсутствие слов в руководстве не доказывает, что endpoint AFRINIC не возвращает JSContact. Оно не доказывает нарушение профиля NRO или иного стандарта, поломку клиента, утечку данных или операционный инцидент. В этой работе не использовалось наблюдение живого ответа endpoint. Речь идёт только о том, как публичное объявление соотносится с публичным описанием, которым пользуется клиент.

Нельзя подменять запись 2022 года поздней спецификацией

Хронология делает осторожность необходимой. Уже в апреле 2022 года существовал Internet-Draft IETF об использовании JSContact в ответах RDAP. Одиннадцатая версия была рабочим документом, описывала расширение для контактных данных сущностей и использовала, среди прочего, название jscard. То, что она предшествует записи AFRINIC, не доказывает её внедрение AFRINIC и не создаёт для AFRINIC обязательства.

Текущая версия черновика августа 2026 года использует более поздние термины: jscontact_card, выбор представления по запросу клиента, сигнал rdapConformance и этапы перехода между jCard и JSContact. Этот документ полезен как техническое сравнение: он показывает, что имя формата не отвечает само по себе на вопросы о формате по умолчанию, явном запросе, метке ответа и совместимости. Но он не является ретроспективным тестом реализации AFRINIC в 2022 году.

Текущий реестр JSContact IANA отдельно указывает основные версии 1.0 и 2.0. Он не называет версию, используемую AFRINIC. Он лишь подтверждает узкую мысль: общее название может быть недостаточно точным для описания публичного интерфейса.

У AFRINIC есть сильная причина не превращать справочную страницу в публикацию внутренней архитектуры. Регистратура не обязана раскрывать реальные контакты, ключи, настройки безопасности, журналы трафика или закрытый план миграции. Краткий журнал и руководство по частым запросам сами по себе оправданны.

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

Проверяемость без изъятия полномочий

Такая запись не предписывает AFRINIC выбрать JSContact или jCard и не задаёт дату миграции. Решение о представлении и эксплуатации остаётся у регистратуры. Запись нужна лишь затем, чтобы внешний читатель не превратил фразу «добавлена функция» в никогда не опубликованное обещание версии, поведения по умолчанию или совместимости.

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

Источники

  1. AFRINIC Online Services Changelog
  2. Руководство по службе RDAP AFRINIC
  3. IETF draft-ietf-regext-rdap-jscontact-11
  4. IETF draft-ietf-regext-rdap-jscontact
  5. Реестр IANA JSContact