Кратко

  • Для одиночных связей rdap-up и rdap-top RFC 9910 разрешает ссылку на поиск либо на обычный lookup, который давал тот же ответ в момент формирования документа.
  • Если база изменилась до перехода, результат может стать другим. Исходный ответ, контекст связи и каждое позднее разрешение следует хранить как отдельные наблюдения.

В материалах проверки сохранились ответ о дочерней сети, время получения и ссылка rdap-up на вышестоящий handle. Через несколько часов аналитик открыл её и записал возвращённый объект. Система совместила две части и представила их как историческую иерархию одного момента.

Однако верхний объект в исходный момент никто не получал. Поздний ответ доказывал только позднее состояние сервера. Он не восстанавливал прежнее представление и не подтверждал неизменность между запросами.

Это условный пример, не утверждение о конкретном реестре. Он показывает временную границу, которую RFC 9910 формулирует прямо, а компактная модель данных может потерять.

Стандарт добавляет базовые, отношенческие и обратные поиски для IP-сетей и номеров автономных систем. rdap-up находит ближайший менее специфичный объект, покрывающий ресурс. rdap-top — самый общий покрывающий объект. Оба поиска возвращают один объект как при прямом запросе либо HTTP 404.

rdap-down и rdap-bottom относятся к множественным результатам. Здесь это только граница темы: статья не превращает bottom в список потомков и не повторяет наблюдавшийся пример ARIN. Вопрос — что один верхний линк способен доказать спустя время.

Сервер может поместить в ответ URL соответствующего поиска. Он вправе использовать и другой URL, дающий тот же результат на момент запроса. Для одиночной связи таким заменителем становится обычный адрес найденного объекта.

Замена удобна, но равенство датировано. Если состояние базы изменилось до разрешения ссылки, предупреждает RFC 9910, lookup способен выдать не тот результат, который дал бы исходный поиск.

Строка href при этом может не измениться. Один адрес выбирает разные представления в разное время. Ссылка сохраняет путь, а не содержимое на его конце. Архив URL — это архив ссылки, но не наблюдения.

RFC 9083 требует в RDAP-ссылке value, rel и href: контекст, отношение и цель. По общей модели RFC 8288 ссылка есть типизированная связь ресурсов. Её тип не фиксирует все будущие представления цели.

Обнаружение авторитетного сервиса тоже не создаёт историю. RFC 9224 определяет, куда направить запрос об адресе, префиксе или ASN. Это выбор полномочного источника, но не обещание неизменности его ответов.

Время должно стать частью доказательства. Ответ о дочернем объекте — первое наблюдение. Немедленный запрос верхнего объекта был бы вторым. Обращение на следующий день — третьим. У каждого должны быть исходные байты, hash, URL, время приёма, HTTP-статус, Date, валидаторы, список соответствия и аутентифицированный endpoint.

По RFC 9110, Date обозначает время происхождения сообщения. ETag и Last-Modified при наличии помогают описать или проверить выбранное представление. Они не являются номерами транзакций реестра и не объясняют изменение.

RFC 9111 отделяет свежесть кэша от истории базы. Свежий ответ может отражать только что изменённую запись. Ещё пригодный для повторного использования ответ может предшествовать исследуемому решению. Свежесть HTTP не доказывает исторического тождества.

Фильтр status меняет видимую иерархию. RFC 9910 рассчитывает отношение так, будто объекты без нужного статуса удалены. Запрос active может перепрыгнуть ближайшее покрытие и выбрать другой слой. Это отфильтрованная связь, а не безусловное утверждение о родителе.

Поддержку функций нужно наблюдать. Необслуживаемая комбинация фильтров может получить HTTP 501. Присутствие отношенческих ссылок в ответах необязательно. Поэтому отсутствие ссылки не доказывает нулевой результат явного поиска. Иначе необязательное оформление превращается в выдуманное отрицательное свидетельство.

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

Условные запросы полезны при наличии валидаторов. Ответ 304 может поддержать узкое заключение об этой выбранной репрезентации по правилам HTTP. Он не доказывает результат неотправленного поиска, другого фильтра или раннего состояния, которое не было захвачено.

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

Идея Heng Lu из Running-Code Primacy здесь практична: спецификация задаёт совместимый вопрос, а состояние работающего сервера и сохранённый ответ дают проверяемый ответ.

Minimum Initial Specification предлагает узкое общее ядро и локальные проверяемые решения. Общими остаются типы связей; сроки хранения, сравнение и эскалация требуют назначенного владельца.

Reality Layers не позволяет точному символическому факту подменить другие слои реальности. Data Sovereignty так же разделяет формальный контроль записи и практический контроль сети.

RFC 9910 сделал иерархию удобнее для обхода, но не остановил время. Сохранение дочернего ответа, первого ответа цели и поздних обращений превращает ссылку в честную связь между наблюдениями, а не в выдуманный снимок.

Источники