Кратко

  • Проект ECRIT добавляет к LoST упорядоченный опрос плановых изменений, проверку для заданного времени asOf и совет revalidateAfter. Клиент может выделить затрагиваемые записи и подготовить замену до даты вступления изменений в силу.
  • Два запроса с одинаковым будущим asOf, отправленные в разное время, могут вернуть разные результаты. Ответ отражает текущие сведения сервера и не гарантирует будущий мэппинг или действие клиента.
  • Следует сохранять отдельные квитанции подготовки и переключения. Это редакционное предложение Daniel Kade, а не требование IETF и не свидетельство внедрения.

Адрес проходит через дату, а место остаётся

Проект Validation of Locations Around a Planned Change начинает с присоединения части района к муниципалитету. До установленного момента поле муниципалитета может быть пустым или иметь другое значение, после — содержать новое название. Переименование и перенумерация улиц создают такой же переход.

Редакция 18 — активный Internet-Draft рабочей группы ECRIT. Это незавершённый документ, не RFC. Он не доказывает ни внедрение, ни принятие стандарта, ни реальный сбой экстренной связи.

RFC 5222 определяет LoST. Клиент отправляет местоположение и идентификатор услуги; сервер возвращает URI услуг и сопутствующие сведения. Запрос также может потребовать проверки элементов гражданского адреса. Формат таких элементов задаёт RFC 5139.

Без предупреждения клиенту приходится периодически перепроверять всю базу. Редкая проверка опоздает к дате, частая создаст лишнюю нагрузку. Проект позволяет серверу сообщить набор мест, которые могут измениться, а клиенту — заранее проверить новый вариант.

Преимущество состоит в готовности. Граница доказательства проходит по времени наблюдения. Запрос в понедельник о пятнице остаётся понедельничным свидетельством.

У трёх часов разные владельцы

Первые часы принадлежат потоку изменений. Отдельный REST/JSON-интерфейс позволяет узнать версии, опросить очередь и получить ChangeSet. В набор входят упорядоченный идентификатор, момент вступления в силу и частичные местоположения. Клиент хранит последний ID и запрашивает последующие.

Вторые часы — asOf. Клиент указывает дату и время в findService. Сервер отвечает исходя из того, что в момент запроса считает действующим к выбранной дате. Если ответ относится не к текущему времени, он должен повторить asOf, а мэппинги получают NO-CACHE.

Третьи часы — следующая проверка. revalidateAfter советует, когда можно снова проверить запись. NO-EXPIRATION сообщает лишь, что сервер сейчас не знает планового изменения, которое повлияет на результат, и не предлагает срок. Это не обещание вечной действительности.

Поток отвечает, что появилось после сохранённой позиции. asOf даёт сегодняшнюю проекцию. revalidateAfter предлагает время нового вопроса. Ни один механизм не подтверждает административный акт, обновление базы клиента, неизменность услуги или доставку сообщения.

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

Частичное местоположение формирует выборку

Нет необходимости перечислять полные адреса. Частичное местоположение состоит из пар пространства имён, элемента и значения. Клиент сравнивает их со своими строками. Если совпали все переданные пары, строка может быть затронута; отсутствующие поля не участвуют в сравнении.

Так можно охватить административную территорию независимо от улиц и домов либо улицу независимо от номеров. Это удобный селектор кандидатов, но не приговор каждой записи.

Клиенту нужно сохранять снимок базы, правило совпадения, кандидатов, исключения и ручные решения. Итоговое число не объяснит, почему повторный запуск дал другой набор: из-за реальной границы, исправления данных, трактовки схемы или ошибки фильтра.

Такое разделение соответствует принципу Lu Heng о минимальной начальной спецификации и локальном будущем решении. Общий слой предоставляет строгие данные для совместимости. Дальнейшее включение остаётся ответственностью тех, кто запускает код.

Возможность пересмотра делает прогноз честным

Проект прямо допускает разные ответы для одного будущего asOf в разное время. Сервер может узнать о новой плановой или внеплановой корректировке и не гарантирует следующий ответ для того же места.

Присоединение могут отложить, список улиц — исправить, источник — обновить позднее. Запрет пересмотра защищал бы план от действительности, которую план должен обслуживать.

NO-CACHE переносит эту скромность в техническое поведение. Кроме того, клиент, которому реально требуется связаться с услугой, всё равно должен обратиться к LoST в соответствующий момент. Подготовленная адресная запись не заменяет текущее разрешение услуги.

Устав ECRIT охватывает механизмы, использующие местоположение и маршрутизацию для связи с подходящим центром реагирования. Решения должны работать между регионами и юрисдикциями без единого центрального органа. Значит, гражданская валидность не доказывает успешную связь, а прогноз одного сервера — работу всех независимых клиентов.

Принцип Lu Heng о реальности вместо агитации требует полной формулы: конкретный сервер в конкретное время дал ответ о конкретной будущей дате. Для слов «вступило в силу» нужен другой источник.

Упорядоченная очередь тоже теряет начало

Опрос предполагается каждые несколько минут. Клиент передаёт последнюю ChangeSet ID, сервер возвращает новые. Пустой список означает лишь, что переданный ID — последний известный серверу сейчас.

Новый клиент или клиент, потерявший позицию, делает запрос без ID и получает все ещё хранимые наборы. Бессрочное хранение не требуется. Проект приводит примеры двенадцати месяцев в стабильной области и трёх месяцев там, где изменения часты.

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

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

В Policy Mirror Lu Heng отделяет реестр от трона. Запись заслуживает доверия в своей функции, но не должна свидетельствовать о действиях за пределами наблюдения.

Две квитанции вместо преждевременного итога

Квитанция подготовки включает сервер, версию интерфейса, время опроса, прежний и новые ID, дату действия и частичное местоположение. К ним присоединяются снимок базы, правило выбора, кандидаты и исключения. Для проверки сохраняются местоположение, услуга, asOf, ответ, revalidateAfter, режим кэша, часы и редакция проекта.

Квитанция переключения начинается с фактической операции: принятый оператором момент, отключение старых строк, включение новых, современная проверка, отличия от прогноза, отложенные и неуспешные случаи, откат и ответственный за закрытие.

Двухэтапная форма — предложение статьи, а не норма проекта. Детальные адресные данные можно защищать, а публично показывать числа, интервалы, ссылки на ChangeSet и незакрытые исключения. Хеш связывает представления, но не делает решение правильным.

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

Интервал — это распределение риска

Проект связывает срок проверки со свежестью, нагрузкой сервера, стабильностью источника и политикой. Он приводит пример шести месяцев и более для устойчивых районов и 20–30 дней для быстро растущих. Это иллюстрации, не общий норматив.

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

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

Предел утверждения

Первая квитанция доказывает, что один клиент получил определённый ChangeSet, сравнил его с заданным снимком и получил будущую проверку. Вторая показывает, что этот клиент позднее включил и какой результат увидел тогда.

Вместе они не доказывают юридическую силу административного акта, согласованность всех серверов, неизменность мэппинга или сквозную доставку. Для каждого вывода нужен свидетель его уровня.

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

Источники