Кратко

  • RFC 5139 заменяет исходный гражданский формат PIDF-LO более богатой XML-моделью на основе типов адресов RFC 4776.
  • Иерархия дороги, участка, ответвления и подответвления сохраняет локальные различия, которые теряет одна строка.
  • Валидность схемы доказывает корректность представления, а не текущее присутствие человека или устройства.
  • Языковые варианты следует хранить отдельными блоками; языковое предпочтение не разрешает фактическое противоречие.
  • XML token сворачивает пробелы, поэтому исходный документ и прикладное значение требуют разных квитанций.
  • Составная позиция допустима только при общем источнике, времени и методе определения.
  • Подробный справочник может быть старым, а грубое измерение — свежим; полнота не равна актуальности.
  • Подпись устанавливает автора утверждения, но не истинность его адресных полей.
  • Комната и место уменьшают область неопределённости, не доказывая занятость.
  • Получатель, цель, детализация, хранение и повторная передача определяются отдельной политикой.
  • LoST и SIP подтверждают этапы проверки и доставки, но не выезд и прибытие.
  • Руководству нужны отдельные состояния для неизвестного, устаревшего, конфликтного, сокращённого и непроверенного.

Чем подробнее запись, тем опаснее ложная уверенность

RFC 5139 устраняет реальный недостаток RFC 4119. Адресные системы разных стран нельзя свести к полям «улица» и «номер». В новую модель вошли здание, блок, комната, место, почтовое сообщество и дополнительные коды, а также RD, RDSEC, RDBR и RDSUBBR.

Номер дома относится к самому конкретному дорожному элементу. Это важно там, где номера повторяются по участкам или одноимённые малые дороги различаются связью с магистралью. Модификаторы основной дороги не переносятся молча на ответвление, а A6 больше не служит запасным полем улицы.

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

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

Выбор языка может скрыть расхождение

Языковые элементы допускают xml:lang; страна и тип места считаются нейтральными согласно их реестрам. Письменность указывается подтегом. Один блок должен использовать один язык или согласованную комбинацию, а параллельные формы остаются отдельными блоками одного tuple.

В DHCP-формате один элемент может повторяться на разных языках. XML-блок допускает один экземпляр, поэтому преобразование создаёт блок на язык. Предпочтения получателя назначают веса, но при равенстве, отсутствии совпадения или конфликте в одном языке RFC 5139 разрешает произвольный выбор.

Это правило поддерживает работу протокола, но не определяет истину. Если сохранить только победившую строку, исчезнет сам факт конфликта. Нужны все варианты, теги, предпочтения, веса и причина выбора.

RFC 5646 стандартизирует обозначение языка и письма. Тождество двух местных названий требует проверенной привязки или компетентного местного источника.

Парсер уже преобразует улику

Гражданские значения основаны на XML Schema token. Обычные пробелы нормализуются и сворачиваются, поэтому разные исходные записи могут дать одинаковое прикладное значение. Преднамеренный пробел можно сохранить ссылкой на символ.

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

Схема допускает элементы других пространств имён и произвольные атрибуты. Две реализации могут принять один документ и понять разные расширения. Необходимо хранить оригинал, версии парсера и схемы, результаты, неизвестные элементы, предупреждения и потери. Значок «валидно» без протокола преобразований недостаточен.

У текущего местоположения должна быть история наблюдения

RFC 5491 разделяет цель, источник, метод определения и протокол доставки. Устройство может служить заместителем человека, но это отдельное утверждение. Ручной ввод, DHCP, сервер местоположения и кадровый справочник имеют разную власть и срок жизни.

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

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

Слово «текущее» разрешает действующее наблюдение, а не количество заполненных полей.

Детализация, уверенность и свежесть — разные оси

RFC 7459 рассматривает местоположение как оценку. В гражданском адресе самый точный доверенный компонент примерно задаёт область неопределённости. Комната уже здания, но остаётся областью; обозначенное место не доказывает присутствия.

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

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

RFC 4589 и реестр IANA стабилизируют словарь, RFC 6848 — расширения. Они не подтверждают фактическое содержание отдельного объекта.

Неполный адрес может быть правильным результатом политики

PIDF-LO сочетает данные и правила использования. RFC 6280 разделяет цель, автора правил, сервер и получателя. RFC 6772 разрешает уменьшать точность. Источник может знать комнату, а получатель законно видеть только город.

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

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

Верная URI ещё не является исходом

LoST сопоставляет услугу и местоположение с сервисной URI и может валидировать гражданский адрес. SIP переносит местоположение или ссылку. Запрос, предупреждения, граница, URI, срок, разрешение и доставка — отдельные квитанции.

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

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

RFC 5139 улучшает описание. Надёжная система не превращает эту локальную истину в глобальное свидетельство присутствия.

Источники

  1. RFC 5139, HTML
  2. RFC 5139, текст
  3. Запись RFC Editor
  4. IETF Datatracker
  5. История документа
  6. Поиск исправлений
  7. RFC 4119: PIDF-LO
  8. RFC 4776: гражданский адрес DHCP
  9. RFC 5491: использование PIDF-LO
  10. RFC 7459: неопределённость и уверенность
  11. RFC 7378: доверенное местоположение
  12. RFC 6280: архитектура местоположения и приватности
  13. RFC 5222: LoST
  14. RFC 6442: местоположение в SIP
  15. RFC 6772: политика геолокации
  16. RFC 6848: расширения гражданского местоположения
  17. RFC 5646: языковые теги
  18. RFC 4589: типы мест
  19. Реестр гражданских типов IANA
  20. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  21. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  22. Running-Code Primary