Кратко

  • Регистрация по RFC 9176 хранит имя endpoint, базовый URI, ссылки и время жизни; это не квитанция о его текущей работоспособности.
  • Регистрация, обнаружение, сетевая достижимость, аутентификация, ответ ресурса и прикладной эффект требуют разных доказательств с указанием времени.

Resource Directory нужен для обнаружения в ограниченных сетях, а не для постоянного наблюдения за устройствами. Узлы могут спать, а прямое multicast-обнаружение может быть дорогим или непригодным. Поэтому RFC 9176 позволяет endpoints и средствам ввода в эксплуатацию регистрировать, обновлять и удалять сведения о ресурсах в RD; ищущий получает зарегистрированные ссылки. Это общий слой для нахождения описаний, но не пульс описанного оборудования.

Границы утверждения видны уже в составе записи. Она связывает endpoint с именем, базовым URI, временем жизни, местоположением ресурса регистрации внутри RD, набором ссылок и, при необходимости, sector и другими атрибутами. При создании RD возвращает местоположение, которым создатель пользуется для обновления времени жизни, изменения ссылок или удаления записи. Такой ответ означает, что RD создал собственный ресурс регистрации. Он не означает, что устройство будет включено, подключено или будет выполнять ту же службу в момент следующего поиска.

Время жизни — не второстепенная деталь. Регистрация является мягким состоянием и должна периодически обновляться. После истечения срока RD не должен выдавать результаты обнаружения для данного endpoint. Однако он может оставить ресурс регистрации, чтобы поздно вернувшийся endpoint мог его обновить, а затем удалить его при сборке мусора. Поэтому административный объект, остающийся после истечения срока, не доказывает возвращение endpoint, восстановление службы или выполнение задачи. Это может быть лишь следствием автомата состояний каталога.

Результат поиска столь же ограничен ссылками. RD возвращает ссылки, переданные при регистрации, и разрешает относительные ссылки относительно базового URI. Так можно увидеть, как регистрант описал ресурс в определённый момент. Но поиск не выполняет с позиции ищущего проверку соединения с URI. Он не проверяет текущий маршрут, транспорт, учётные данные, полномочия конкретного клиента, обработку ресурса или физический эффект. URI может оставаться корректным, когда endpoint выключен; ответ ресурса может быть формально успешным без обещанного приложением результата.

Идентичность и полномочия также нельзя автоматически извлечь из полей каталога. RFC 9176 отмечает, что протокол, порт и IP-адрес недостаточны для идентификации endpoint, поскольку они могут меняться в течение его жизни. Кто вправе использовать имя endpoint или sector, решает конкретная политика безопасности; доступ к регистрации и доступ к поиску следует контролировать отдельно. Возможность прочитать ссылку не даёт права управлять ресурсом, а возможность записать регистрацию не превращает её содержание в устойчивый факт.

Проверяемая эксплуатационная запись поэтому отделяет запрос регистрации и ответ RD, возвращённое местоположение, авторизацию имени и sector, базовый URI, ссылки, время жизни и историю обновлений. Результат поиска получает время и место наблюдения. Для утверждения о доступности службы нужны отдельные прямые проверки достижимости, результаты транспорта и аутентификации, запрос и ответ ресурса, а также свидетельство прикладного эффекта. Это соответствует дисциплине Lu Heng: общая минимальная поверхность снижает цену координации, но не забирает решения у оператора и не заменяет наблюдение за работающим состоянием.

Источники