Кратко
- Элемент
redactedможет назвать скрытое поле, указать способ обработки и путь в структуре до или после редактирования. Он фиксирует утверждение сервера о выданном ответе, но не хранит и не проверяет исходное значение. - Причина необязательна, содержание политики находится вне RFC, а само признание существования поля иногда можно опустить ради приватности. Для аудита отдельно нужны запрос, сервер, класс доступа, время, исходный JSON, проверка путей и версия политики.
Два одинаковых пробела
В двух карточках домена не показано имя регистранта. В первой базе такого значения нет. Во второй имя хранится, но анонимный клиент его не получает. Если система оценки качества помечает обе карточки как «неполные данные», она приписывает ответам историю, которой в видимом JSON нет.
RFC 9537 опубликован в марте 2024 года как документ Standards Track IETF для решения именно этой узкой неоднозначности. Он описывает расширение, с помощью которого сервер RDAP отмечает удалённые, опустошённые, частично скрытые или заменённые поля. Авторы — James Gould, David Smith, Jody Kolker и Roger Carney. В профиле IETF, зафиксированном 7 сентября 2026 года, с Gould связано тринадцать RFC. Биография комитета Registration Operations Workshop называет его fellow Verisign, отвечающим за архитектурное и техническое направление сервисов доменных реестров.
Это подтверждает рабочий контекст и совместное авторство, но не единоличное изобретение и не контроль над чужими внедрениями.
Спецификация сильна тем, что не обещает лишнего. Она даёт общую форму утверждению сервера о собственной выдаче. Скрытая запись и основание решения остаются за пределами этого утверждения.
Что связывает redacted
Ответ с расширением указывает redacted в rdapConformance. Объект со скрытыми полями обычно содержит массив описаний. В каждом элементе обязателен логический name: зарегистрированный type либо свободное description.
Путь привязывает имя к структуре. prePath указывает место до удаления и потому может не разрешаться в полученном документе. postPath указывает на сохранившееся пустое, частичное или заменяющее значение. Одновременно они не используются. replacementPath способен указать отдельное поле-замену. Языком по умолчанию служит JSONPath из RFC 9535.
Этого достаточно, чтобы записать: сервер назвал конкретное поле скрытым и сообщил метод. Но путь не содержит прежних байтов. Он не доказывает правильность внутренней базы, личность предполагаемого владельца и корректность расчёта полномочий клиента. Координата в JSON — не удостоверение фактов за JSON.
Реестры IANA закрепляют идентификатор расширения и общие классы имён, причин и языков выражений. Регистрация улучшает совместимость, но не сертифицирует отдельный ответ и не одобряет локальную политику.
Четыре метода оставляют разные следы
При removal поле или объект исчезает из выдачи. Это метод по умолчанию, если method не указан, кроме случаев, где смысл зависит от позиции элемента массива. Для позиционных массивов jCard emptyValue сохраняет место, подставляя пустую строку или null. PartialValue оставляет часть форматированного значения. ReplacementValue выдаёт другое значение или поле, например анонимизированный адрес либо форму связи.
Интерфейс может показать один значок для всех вариантов, однако доказательства различаются. Удалённый объект нельзя проверить как пустую позицию. Часть адреса всё ещё раскрывает информацию. Форма поддерживает канал связи, но не становится исходной почтой регистранта. RFC также запрещает заполнители из повторяющихся букв: произвольный текст может нарушить формат поля и выглядеть настоящими данными.
Поэтому хранить надо фактическую форму JSON, метод и путь. Скриншот с надписью «скрыто» уничтожает именно то различие, которое расширение призвано сохранить.
Причина не выносит решение о политике
В описании может присутствовать reason как зарегистрированный тип или понятный человеку текст. Текст нельзя делать зависимостью обработки клиента. Фраза «политика сервера» не является стабильным машинным правилом допуска.
Сервер вправе опубликовать политику редактирования, но её содержание не входит в RFC 9537. Стандарт не решает вопрос о согласии, применимом праве, интересе заявителя или правомерности отказа. RFC 7481 предоставляет аутентификацию и ступенчатый доступ по местной политике. Поэтому два клиента могут законно получить разные представления объекта.
Профиль ответов RDAP ICANN 2024 года показывает, как конкретная среда добавляет следующий слой. В пределах охваченных gTLD-сервисов он сопоставляет элементы регистрационных данных именам и методам RFC 9537 и задаёт обработку электронной почты. Это существенное эксплуатационное требование в своей области, но не всеобщая политика RDAP и не решение по каждому запросу.
Есть ещё одна асимметрия. Само признание того, что скрытое поле существует, способно раскрыть информацию. RFC разрешает не включать описание, когда сигнал существования создаёт риск приватности. Отсутствие redacted не доказывает полноту: сервер мог ничего не скрывать, не поддерживать расширение или сознательно не подтверждать наличие поля.
Минимальный комплект квитанций
Сначала фиксируются точный URI и вид запроса — lookup или search, авторитетный сервер, перенаправления, время, транспортная идентичность, аутентификация и класс полномочий. Анонимный и привилегированный запрос одного домена — разные наблюдения.
Затем сохраняются байты ответа или проверяемый хеш, значения rdapConformance, идентификатор объекта и для каждого элемента имя, язык пути, путь, метод и причина. Отчёт отмечает, разрешился ли postPath, как истолкован отсутствующий prePath, и версии клиента RDAP и реализации JSONPath. Иначе обновление парсера можно принять за смену политики сервера.
Для связанной политики нужны URL, наблюдавшаяся версия и дата. Позднее изменённая страница не доказывает правило, действовавшее раньше. При сравнении представлений каждое остаётся связано со своим классом доступа.
RFC 9082 различает lookup и search. В поиске описание относится к отдельному объекту результата. Ограничение всего набора не равно сокрытию поля. Notices и remarks из RFC 9083 дополняют контекст ответа или объекта, но не заменяют структурированный сигнал для поля.
Такой комплект позволяет сделать соразмерный вывод: этот сервер для этого запроса, времени и доступа описал поле как скрытое указанным способом. Исходное значение, полномочие политики и право клиента требуют самостоятельных доказательств.
Источники
- RFC 9537 — Скрытые поля в ответе RDAP
- RFC 9083 — Ответы JSON для RDAP
- RFC 9082 — Формат запросов RDAP
- RFC 7481 — Сервисы безопасности RDAP
- RFC 9535 — JSONPath
- Реестр расширений RDAP IANA
- Реестр значений JSON RDAP IANA
- Профиль James Gould в IETF
- Биография комитета Registration Operations Workshop
- Публичный портрет Registration Operations Workshop
- Профиль ответов RDAP ICANN 2024 года
- Техническое руководство RDAP ICANN 2024 года
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
