Кратко

  • findServiceResponse фиксирует выбранное описание места, источник и версию отображения, срок действия, границу обслуживания, путь разрешения и контактный URI. Это квитанция о переводе, а не об отвеченном вызове.
  • RFC 5222 явно кодирует неполные состояния: непроверенные поля адреса, просроченную карту, замену услуги, URI по умолчанию и перенаправление. Даже ошибка LoST передаётся внутри HTTP 2xx.
  • Надёжный вывод собирается из раздельных свидетельств: получение места, выбор и проверка, актуальная карта, решение о кэше, граница, попытка сеанса, принятие вызова и итог услуги.

Зелёным оказался не тот этап

Возьмём искусственный сценарий аудита, а не реальное происшествие. В 08:14:02 устройство передаёт civic-адрес, запрашивает urn:service:sos.police и просит проверить адрес. В 08:14:03 рекурсивный резолвер возвращает SIP URI, ссылку на границу, locationUsed, путь via, а также source, sourceId, lastUpdated и expires.

В 08:14:04 панель сообщает: «маршрутизация успешна». В 08:14:20 в данных всё ещё нет подтверждения установленного SIP-сеанса, принятия вызова адресатом, медиаканала или результата реагирования. Ответ карты корректен; название показателя присвоило ему смысл, которого протокол не наблюдал.

RFC 5222 определяет Location-to-Service Translation. Гражданское или геодезическое местоположение вместе с URN услуги преобразуется в один или несколько URI и сопровождающие сведения. Последующая сигнализация и работа службы находятся за пределами этого ответа.

locationUsed сохраняет выбор, но не происхождение

В запросе может быть несколько элементов location. Сервер выбирает понятный ему профиль и возвращает идентификатор в locationUsed. Благодаря этому можно установить, какой вход породил результат.

Идентификатор не сообщает, кто получил координаты, когда, с какой погрешностью и не переместилось ли устройство. RFC 4119, RFC 5139 и RFC 5491 задают объект местоположения, civic-формат и правила PIDF-LO. RFC 5985, RFC 5986 и RFC 6155 отдельно рассматривают доставку местоположения, обнаружение LIS и идентичность устройства.

Такое разделение защищает от простой ошибки: валидная структура не доказывает текущего присутствия. LoST способен безупречно обработать устаревший вход. Корректность алгоритма тогда не равна пригодности результата.

Проверка civic-полей тоже ограничена. При validateLocation=true сервер может перечислить valid, invalid и unchecked. Valid означает, что поле распознано и использовано при отображении; unchecked — что оно не проверялось и не использовалось. Противоречия разрешаются локальной политикой. Это проверка ключей сопоставления, а не свидетельство нахождения человека по адресу.

Версия карты и возраст события — разные часы

Каждый mapping несёт source, sourceId и lastUpdated. Значения создаёт авторитетный источник; кэш не должен их менять. Более новый lastUpdated при той же паре source/sourceId позволяет заменить старую версию.

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

expires задаёт предел повторного применения. Допустимы абсолютная дата, NO-CACHE и NO-EXPIRATION. RFC 5222 допускает, что сервер в крайнем случае вернёт просроченную карту обычным ответом. Клиент обязан прочитать срок и зафиксировать локальное решение.

Есть и пространственная граница. Если устройство вышло из области обслуживания, кэш теряет применимость до наступления времени expires. Поэтому отдельно нужны время наблюдения места, lastUpdated, expires, положение при повторном использовании и время попытки сеанса.

NO-EXPIRATION — свойство политики карты. Оно не утверждает, что учреждение, сеть или конечный URI никогда не изменятся.

Ссылка на границу создаёт второй этап проверки

Граница может прийти значением либо как serviceBoundaryReference с source и key. Клиент выражает предпочтение, но форму выбирает сервер. Получив ссылку, клиент направляет getServiceBoundary прямо авторитетному серверу; рекурсии здесь нет.

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

RFC 5582 описывает более широкую архитектуру. Граница ограничивает условия безопасного повторного использования ответа; она не делает единожды полученный URI вечным.

Путь резолвера не продолжается автоматически до диспетчера

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

Но path не является универсальной подписью всех полномочий. Он сам по себе не доказывает честное DHCP/DNS-обнаружение, проверку TLS-имени на каждом звене, свежесть каждого кэша и достижимость итогового URI.

RFC 5223 описывает обнаружение LoST через DHCP. RFC 8917 вводит отдельный тег для сервиса валидации. RFC 5069 рассматривает угрозы маркировке и отображению экстренных вызовов. Обнаружение, защищённый транспорт, карта и валидация дополняют, но не заменяют друг друга.

RFC 5222 требует реализации TLS и рекомендует его использование с проверкой идентичности сервера. Это снижает риск подмены, перехвата и отравления кэша. TLS защищает переданные данные; он не исправляет ошибочное место и не заставляет URI отвечать.

HTTP 200 подтверждает доставку XML, а не экстренной помощи

Все ответы LoST, включая предупреждения и ошибки, перевозятся HTTP-ответами 2xx, обычно 200 OK. По коду транспорта нельзя понять, содержится ли точная карта, redirect, ошибка или аварийный вариант.

locationValidationUnavailable разрешает вернуть карту и одновременно сообщить, что запрошенная проверка недоступна. serviceSubstitution отмечает замену вида услуги. defaultMappingReturned означает, что указанное место не удалось обслужить точно и был выдан URI по умолчанию, например ближайшего PSAP.

Default может быть разумной деградацией. Но если предупреждение исчезнет, запасной вариант будет выглядеть как точное совпадение юрисдикции. Ложь рождается не в fallback, а в потере его статуса.

Зафиксированная страница errata содержит две подтверждённые записи, одну сообщённую и две отложенные до обновления документа. Статус Standards Track не заменяет учёт конкретной редакции и поправок в работающем коде.

Подпись синхронизации не подписывает результат вызова

RFC 6739 определяет обмен картами между узлами LoST. Он сравнивает source/sourceId/lastUpdated, запрещает изменять полученные mapping и требует подписей авторитетных источников, чтобы участник не мог самовольно объявить чужую область своей.

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

RFC 5031 определяет URN класса услуги. RFC 5012 формулирует требования к разрешению экстренного контекста. RFC 6881 описывает более широкую практику устройств и сетей. Назвать услугу, найти адрес и оказать помощь — разные операции.

Честный итог собирается из узких утверждений

Нужно связать: источник и время места; выбранные ID и профиль; civic-валидацию; URN; обнаружение, DNS и TLS; рекурсию и redirect; source/sourceId/lastUpdated; expires, кэш и движение; границу; URI и предупреждения; попытку и установление сеанса; принятие и результат.

Если доказательства заканчиваются на URI, там же должен закончиться вывод: «карта вернула этот контакт». Следующее предложение требует данных от следующей системы.

Sources

  1. RFC 5222
  2. RFC 5222 в Datatracker
  3. Статус RFC 5222
  4. История RFC 5222
  5. Errata RFC 5222
  6. RFC 5139
  7. RFC 4119
  8. RFC 5491
  9. RFC 5012
  10. RFC 5031
  11. RFC 5223
  12. RFC 6739
  13. RFC 6881
  14. RFC 5582
  15. RFC 5069
  16. RFC 8917
  17. RFC 5985
  18. RFC 5986
  19. RFC 6155
  20. Heng Lu — Running-Code Primacy
  21. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption