Кратко

  • RFC 3982 различала private и denied: первое объясняло возможный постоянный запрет публикации, второе — отказ на текущем уровне доступа.
  • Для выданных значений specialAccess и doNotRedistribute отделяли привилегию просмотра от права на дальнейшее распространение; метки сообщали политику, но сами её не исполняли.

Проблема пустого поля становится видна не в момент запроса, а годы спустя. В журнале осталась строка без контакта. Если причина не была сохранена, аудитор не узнает, отсутствовал ли контакт в реестре, был ли он навсегда закрыт или ответ зависел от полномочий прежнего пользователя. Формально выгрузка цела. Как доказательство она неполна.

RFC 3982 включила причину такого отсутствия в модель ответа. Страница статуса, страница исправлений и история Datatracker фиксируют документ Standards Track января 2005 года. Он определял доменный тип реестра IRIS: структурированные запросы и результаты для доменов, узлов, контактов, регистраторов и регистрирующих органов.

Идея исходила из требований CRISP. RFC 3707, её статус, исправления и досье IETF требовали не мешать оператору назначать разные уровни доступа по собственной политике. Невыданное значение должно было допускать три представления: полное отсутствие объяснения, недостаточную авторизацию и ограничение приватности независимо от авторизации. Выданное значение должно было поддерживать метки «не распространять» и «предоставлен особый доступ», в том числе одновременно.

Историческим фоном был WHOIS. RFC 3912, статус, исправления и Datatracker описывают текстовый запрос к TCP-порту 43 и текстовый ответ. Сам документ признаёт отсутствие сильной защиты, контроля доступа, целостности и конфиденциальности. Оператор мог добавить пояснение для человека, но общего машиночитаемого поля для причины пропуска не было.

В разделе 3.2.1 RFC 3982 некоторые типы результатов могли присутствовать с содержимым или без него. Если соответствующий элемент присутствовал пустым, он обязан был иметь хотя бы один из двух логических атрибутов. private означал, что содержимое отсутствует, потому что его, возможно, нельзя публиковать никогда. denied означал, что политика не разрешает выдать его на текущем уровне доступа.

Различие определяло следующий шаг. При denied иной класс пользователя мог получить значение, хотя протокол этого не обещал. private задавал более постоянную границу публикации. Ни одна метка не утверждала, что значения нет в базе. Если же элемент полностью пропущен, стандартизированного объяснения не остаётся.

Для присутствующего содержимого действовала другая пара. specialAccess сообщал, что значение выдано благодаря особым правам. doNotRedistribute сообщал, что получатель не должен передавать его дальше. Первая метка объясняла источник доступа, вторая ограничивала дальнейшее действие. Их сочетание не позволяло считать привилегированный просмотр неограниченной лицензией на публикацию.

Посредник легко стирает эту модель. XML-преобразователь сохраняет текст и теряет атрибуты. Хранилище превращает nil в пустую строку. Интерфейс показывает контакт, но не показывает запрет передачи. Общий кэш объединяет публичный и привилегированный ответы. Символы остаются точными, а происхождение и полномочия исчезают.

Метки не были самостоятельной защитой. RFC 3981 и её статус помещали отказ в разрешении и предварительную проверку полномочий в ядро IRIS, но полагались на прикладной транспорт для аутентификации и приватности. RFC 3983 и её статус определяли транспорт через BEEP. Атрибут не шифрует, не удостоверяет пользователя, не блокирует копирование и сам по себе не создаёт юридическую санкцию. Он переносит решение политики.

Та же неоднозначность возникла в RDAP. RFC 9083, её статус, исправления и история задают модель JSON-ответа. RFC 9537, статус, исправления и запись IETF добавляют явное описание редактированных полей.

RFC 9537 различает удаление, пустое, частичное и заменённое значение. Расширение может указать поле, метод и причину. Общие заглушки вроде XXXX отвергаются как ненадёжный сигнал, способный нарушить формат. Документ учитывает и обратную утечку: сообщение о редактировании подтверждает существование данных. Когда это само по себе чувствительно, сервер может не показывать такую метку.

Официальные источники не доказывают прямую генеалогию от RFC 3982 к RFC 9537; приписывать её было бы ошибкой. Они доказывают устойчивость проблемы. Пустота без причины не является полным фактом. Видимое значение без условий доступа не является полным разрешением. История RFC 3982 важна потому, что протокол отказался сводить четыре разных состояния к двум колонкам «есть» и «нет».

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

Источники