Кратко

  • draft-ietf-calext-vcard4-bis-00 определяет обязательные связи по UID и PID, запрещает некоторые сопоставления и оставляет остальные одноимённые свойства на усмотрение механизма синхронизации.
  • Итоговая карточка фиксирует обслуживаемое состояние. Чтобы доказать происхождение этого состояния, отдельно нужны входные хэши, правило, решение, преобразование контекста и полномочие участника.

Снимок отвечает на другой вопрос, чем журнал

Распределённой системе удобно хранить короткий текущий объект. Пользователю нужен контакт, а не бесконечная история всех редакций. Поэтому пример vCard4-bis после слияния упрощает глобальный контекст: переименовывает локальные номера, сводит источники и удаляет лишнее отображение.

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

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

Редакция 00 пока остаётся рабочим документом

Редакция 00 документа vCard Format Specification датирована 2 июля 2026 года и истекает 3 января 2027 года. Это Internet-Draft рабочей группы CALENDAR EXTENSIONS, предназначенный для Standards Track. При одобрении он заменит RFC 6350. Сейчас это не RFC и не свидетельство внедрения.

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

Но корректное представление не доказывает реальный объект. Синтаксически верная карточка не удостоверяет человека. Успешная синхронизация не подтверждает актуальность телефона. Одинаковый финальный текст не доказывает одинаковый алгоритм принятия решения.

В docs/heng-lu-note.md принцип Running-Code Primacy отделяет публикацию от реализации, проверку от использования, а использование от результата. Minimum Initial Specification оставляет общим только необходимое ядро, а контекстные будущие решения — локальным участникам. Именно так следует читать границы синхронизации vCard.

UID создаёт обязательную связь между представлениями

Документ называет синхронизацией интеллектуальное слияние двух представлений одного объекта. Эквивалентные UID обязывают механизм сопоставить экземпляры vCard.

Если оба значения — допустимые URI, применяется эквивалентность RFC 3986. Иначе после снятия текстового экранирования содержимое сравнивается посимвольно. Благодаря этому копия общей карточки после самостоятельного редактирования не превращается в нового человека при каждом импорте.

Кардинальность UID равна *1: не более одного, но не обязательно ровно один. Если UID отсутствует или не решает вопрос, механизм вправе сопоставить карточки по своему усмотрению. Даже одинаковый UID может быть ошибочно скопирован или намеренно повторно использован.

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

PID строит мост от локального номера к глобальному контексту

После сопоставления карточек нужно распознать отдельные свойства. Первый компонент PID — локальный номер значения. Второй — небольшой номер источника, значимый только внутри данного экземпляра vCard.

CLIENTPIDMAP связывает номер источника с URI. Для каждого используемого источника требуется отображение, а ноль запрещён. Если локальные номера значений совпадают, а номера источников через карту указывают на эквивалентные URI, PID могут обозначать одно глобальное значение.

Так число 1 на двух устройствах не становится глобальным идентификатором случайно. Контекст задаёт карта.

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

Обязательные правила ограничивают произвол

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

Эти правила не позволяют текстовой похожести управлять всем. TEL не становится EMAIL. Поле другого человека не попадает в текущую карточку. Известная идентичность свойства не исчезает из-за предпочтений поставщика.

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

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

Стандарт разрешает решение, но не принимает его вместо оператора.

Два адреса остаются, два телефона сливаются

В примере одновременного редактирования оба устройства добавляют новый адрес электронной почты и новый телефон. Из-за разных контекстов источника свойства получают разные глобальные PID.

Новые адреса не сопоставляются и оба копируются. Телефоны тоже имеют разные PID, но видимые значения одинаковы. «Особенно умный» механизм решает, что это одно свойство, и объединяет их.

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

Финальный TEL содержит оба PID. Это показывает слияние двух линий свойства, но не объясняет его. Сравнивались ли строки, применялась ли нормализация телефонного номера, подтверждал ли пользователь, сработала ли модель?

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

Несогласованная карта требует остановить автоматическую уверенность

CLIENTPIDMAP обрабатывается отдельно и не сопоставляется как обычное свойство. Механизм обязан обеспечить согласованность карт между сопоставленными карточками. Если согласованности нет, редакция 00 оставляет результат механизму и не определяет его.

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

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

Если продукт выбрал одну карту, а затем назвал результат следствием vCard, он замаскировал собственную власть формальной совместимостью.

Упрощение контекста не определено до алгоритма

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

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

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

Но журнал не обязан исчезать. Перед упрощением сохраняются входные хэши, карты источников и конфликты; при преобразовании — соответствие старых и новых номеров; после — хэш результата. Компактная vCard обслуживает чтение, отдельный append-only журнал обслуживает разбор.

Сохранить состояние и сохранить объяснимость — две разные операции.

Защищённая доставка заканчивается до семантического решения

vCard не содержит встроенной аутентификации и конфиденциальности. Редакция 00 упоминает перенос с помощью S/MIME. CardDAV даёт контекст коллекции и ETag, а WebDAV Sync перечисляет изменения после токена.

Каждый механизм создаёт полезную квитанцию. Защищённое сообщение связывает байты с учётными данными. ETag указывает версию. Токен ограничивает набор изменений.

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

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

SOURCE и REV не являются журналом каждого свойства

SOURCE может указать, где получить сведения, REV — когда карточка обновлялась. Они помогают бороться с устареванием.

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

Не нужно превращать vCard в тяжёлый протокол событий. Дополнительное доказательство хранит приложение, которое принимает значимое решение. Чем сильнее последствия, тем полнее локальная квитанция.

Сходимость без объяснимости — слабая метрика

Нужно разделять сопоставления карточек по UID и по эвристике, обязательные PID-совпадения и дискреционные. Следует считать конфликты CLIENTPIDMAP, отменённые пользователем слияния, удалённые альтернативы, упрощения без таблицы преобразования и последующие ошибки связи.

Высокая сходимость при росте отмен означает, что автоматизация быстрее распространяет хрупкие решения.

Сила vCard4-bis в том, что документ показывает конец общего ответа. Формат владеет синтаксисом и определёнными идентификационными связями. Механизм владеет эвристикой. Приложение — конфликтной политикой. Оператор — внедрением и аудитом. Реальность позже показывает, работал ли контакт.

Краткая карточка нужна. Но она не должна оставаться единственным свидетелем собственного появления. Обслуживайте снимок и сохраняйте журнал решений рядом с ним.

Sources