Кратко

  • Проект позволяет клиенту LoST опрашивать поток ChangeSet, находить потенциально затронутые адресные записи и заранее проверять замену для будущего времени asOf.
  • Ответ о будущем отражает знания сервера в момент ответа, помечается NO-CACHE, может измениться и не заменяет актуальный запрос LoST при реальном обращении к службе.
  • Уведомление, непрерывность потока, предварительная проверка, локальная подготовка, переключение, mapping во время вызова, передача местоположения, маршрут к PSAP и результат — разные доказательства.

В полночь меняется действующая запись, а не координаты здания

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

Действующий Internet-Draft предлагает управлять таким заранее известным изменением. RFC 5222 уже даёт LoST-клиенту проверку гражданского адреса и поиск URI службы по местоположению и виду службы. RFC 5139 определяет поля адреса. Новая работа добавляет PlannedChangePoll, GetChangeSet и Versions.

ChangeSet содержит ID, время вступления в силу и частичные местоположения. Клиент сопоставляет их со своими строками, выделяет кандидатов и готовит замену. Запрос asOf проверяет предполагаемое состояние на будущий момент, а revalidateAfter может рекомендовать следующую проверку.

Механизм создаёт время для подготовки. Само переключение он не выполняет.

Прогнозируемый mapping намеренно нельзя кэшировать

Сервер сообщает то, что знает во время запроса о состоянии к указанному asOf. Позже может появиться новый план или незапланированная поправка. Поэтому два запроса об одном будущем моменте могут получить разные результаты, а mapping обязан иметь expires="NO-CACHE".

Когда службу действительно нужно вызвать, LoST всё равно следует использовать в этот момент. Проект тем самым отделяет план от активированного состояния и от фактически выбранного маршрута.

NO-EXPIRATION также не означает вечной действительности. Это лишь утверждение, что сервер сейчас не знает планового изменения и не предлагает конкретный срок повторной проверки. Периодическая перепроверка остаётся необходимой.

RFC 6443 показывает полную цепочку экстренного вызова: получение местоположения, LoST mapping, передача местоположения и маршрута, прокси и функции экстренной маршрутизации, приём в PSAP. RFC 6881 требует при вызове попытаться обновить местоположение и mapping, но допускает сохранённое значение, если обновление не успевает. Предварительная проверка не доказывает, какая ветвь сработала и куда пришёл вызов.

Курсор помнит поток одного сервера, а не согласие всех источников

Клиент хранит последнюю changeSetId и просит последующие записи. Сам текст ID может не выражать порядок; порядок знает сервер. При потере курсора доступны лишь те ChangeSet, которые сервер ещё хранит.

Проверка Security Directorate ставит вопросы о границе: привязан ли ID к серверу, как обрабатывать совпадения между серверами, нужны ли отдельные очереди по источникам и что делать при расхождении властей на одну дату. В ней также отмечено, что OpenAPI, похоже, не описывает параметр старого ID, хотя дальнейший опрос требует его по тексту.

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

Проверка Operations Directorate выявляет ту же проблему у схем. Relax NG из RFC 5222 сохраняет авторитетный статус, а более удобная XML Schema предлагается как неавторитетная альтернатива и база расширения. Успех проверки удобным артефактом нельзя без доказательства эквивалентности выдать за соответствие авторитетному.

Надёжное переключение оставляет несколько квитанций

Уведомление фиксирует сервер, ID, время действия, частичное местоположение и совпавшие строки. Квитанция потока хранит область сервера, предыдущий курсор, возвращённую последовательность, окно хранения и пробелы. Будущая проверка сохраняет время запроса, asOf, точный ввод, ответ и NO-CACHE.

Локальная подготовка описывает новые строки, конфликты, утверждение и расписание. В момент действия нужен новый факт: старые строки отключены, новые активны, ошибки изолированы, откат доступен.

При настоящем вызове доказательства снова начинаются с текущего состояния: полученное местоположение, актуальный LoST mapping, URI PSAP, переданный объект местоположения, путь через прокси и ESRP, приём, установление соединения и ответ. Каждый компонент свидетельствует лишь о состоянии, которым управляет. Связанность процесса не позволяет предыдущему компоненту объявлять результат следующего.

Так документ остаётся описанием, а исполняемая система — источником факта. Для критической инфраструктуры это граница ответственности, а не редакционная тонкость.

Проект ещё проходит оценку

На момент завершения исследования повестка IESG включала редакцию 18 в телеконференцию 24 сентября. Datatracker показывал IESG Evaluation, три позиции DISCUSS, потребность в дополнительных голосах и нерешённые вопросы IANA по регистрации XML. Проверки безопасности и эксплуатации нашли проблемы. Это не утверждённый RFC, не отчёт о внедрении и не результат проверки совместимости.

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

Источники

Первичные документы: текущий Internet-Draft, повестка IESG, проверка безопасности, проверка эксплуатации, RFC 5222, RFC 5139, RFC 6443 и RFC 6881.