要約

  • draft-ietf-calext-vcard4-bis-00 は UID と PID による必須の対応付けを定める一方、それで決まらない同名プロパティの対応を同期エンジンの裁量に残す。
  • 簡略化後のカードは有用な現在状態だが、入力、ヒューリスティック、承認、旧新マッピングを別に残さなければ、完全な由来記録にはならない。

小さな整数に世界的な意味を与える仕組み

一つの vCard には複数の電話番号やメールアドレスが存在し得る。同期時に必要なのは、同じ名前のプロパティを見つけることだけではない。端末 A の二番目の TEL と端末 B の二番目の TEL が、同じ編集の系譜を持つのかを判断しなければならない。

PID の第一フィールドはローカルな値番号である。第二フィールドはソース番号だが、この小さな整数も一つの vCard インスタンスの中でしか意味を持たない。CLIENTPIDMAP はソース番号を URI に対応付け、ローカルな名前空間にグローバル文脈を与える。

これは慎重な設計である。世界中の端末が 1 を使っても、それだけで同じソースだとは主張しない。各カードのマップが、どの URI の文脈に属する 1 なのかを示す。

しかし、URI は署名ではない。UUID のように見える値も、該当端末が本当にプロパティを作成したこと、その端末が変更権限を持つこと、マップが改変されていないことを証明しない。比較可能な名前と、検証済みの保管主体は別物である。

改訂 00 が約束する範囲

改訂 00 は 2026 年 7 月 2 日付で、2027 年 1 月 3 日に失効する。CALENDAR EXTENSIONS ワーキンググループの Internet-Draft で、Standards Track を意図し、承認されれば RFC 6350 を置き換える。まだ RFC ではない。

この文書は、人や組織を表す氏名、住所、電話、写真、鍵、役割、関係などを交換する形式を定義する。独立した製品が共通の構文と IANA 登録値を使えることは、運用上の大きな価値である。

価値を守るには、証明できる範囲を広げ過ぎないことが必要だ。形式が正しいことは実在人物の同一性を証明しない。同期が完了したことは電話番号が現在も正しいことを証明しない。二台の端末が同じ結果に収束したことは、同じ推論過程を実装したことも、その推論が承認されたことも証明しない。

docs/heng-lu-note.md の Running-Code Primacy は、文書、実装、検証、配備、利用、結果を別の出来事として扱う。Minimum Initial Specification は、共有すべき最小限の構造を定め、その後の判断をローカルに残す。vCard4-bis の同期設計は、この境界をよく見せている。

UID はカードを同じ審理に入れる

同期は、同じ対象の二つの表現を知的にマージすることと定義される。UID が等価な vCard インスタンスは、必ず対応付けなければならない。

両方が有効な URI なら RFC 3986 の等価性を使い、それ以外はテキストのエスケープを除いた内容を文字単位で比較する。この規則により、共有後に別々に育ったカードを同じ記録として再認識できる。

ただし UID のカーディナリティは *1 で、最大一個であって必須一個ではない。UID が解決しない場合、エンジンは裁量でカードを対応付けてもよい。さらに、同じ UID は現実の人物が同じことを保証しない。誤った複製や不正利用もあり得る。

UID の権限は狭い。二つの表現を同じ調整手続に入れる力はある。人物確認、フィールドの真実性、マージ同意を与える力はない。

MUST は共通の骨格を作る

同期規則には明確な禁止と義務がある。対応していないカードに属するプロパティ同士を対応付けてはならない。名前が異なるプロパティも対応付けてはならない。

既に対応したカードでは、同名かつ最大カーディナリティが一のプロパティは必ず対応する。同名で PID が同じグローバル値を指すプロパティも必ず対応する。

この骨格があるから、ベンダーごとの推測が形式全体を支配しない。TEL が EMAIL に化けず、別人のフィールドが文字列の類似だけで混入せず、既知の属性同一性が無視されない。

一方、それ以外の同名プロパティはエンジンの裁量で対応付けてもよい。標準は、電話表記、住所表記、名前の揺れ、ユーザー意図を世界共通の一規則で決められないと認めている。

この MAY は責任の空白ではなく、責任の所在である。判断したエンジンは、入力、正規化、規則、信頼度、閾値、決定を記録すべきだ。

同じ電話、異なる PID

同時編集の例では、二台の端末がそれぞれ新しいメールアドレスと電話番号を追加する。各端末の新規プロパティは、異なるソース文脈に属する PID を持つ。

二つのメールはグローバル PID が異なるため、対応しない。双方が最終カードに残る。電話も PID は異なるが、見える値は同じである。例の「特に賢い」同期エンジンは、二つを同一プロパティと判断して一つにまとめる。

これは許可された判断であり、必須判断ではない。二人の編集が本当に同じ番号なら正しい。片方が内線、当番用途、古いソース、低い確信度などの未符号化文脈を持っていたなら、誤りになり得る。

最終 TEL は二つの PID を保持するため、二つの属性系譜が合流したことは分かる。しかし、なぜ合流したかは分からない。文字列比較か、電話番号正規化か、ユーザー確認か、機械学習モデルか。カードだけでは判定できない。

運用側は、元値とハッシュ、元 PID、CLIENTPIDMAP、正規化結果、アルゴリズム版、信頼度、ポリシー判定、実行主体を別の決定記録に残す必要がある。

マップ不整合で標準の回答は終わる

CLIENTPIDMAP は通常のプロパティのようにはマッチされない。同期エンジンが別に扱い、対応するカード間で整合性を確保しなければならない。不整合がある場合の結果はエンジンに委ねられ、改訂 00 では未定義である。

不整合には複数の原因がある。正当な再番号付け、古い複製、衝突、破損、ソース置換である。異なる信頼モデルを持つ全システムに一つの自動解決を強制するのは危険だ。

未定義だからといって、黙って上書きしてよいわけではない。入力を保存し、自動破壊処理を止め、理由コードを出し、ローカル方針に渡す。個人向けなら確認画面、企業向けなら隔離、署名履歴があるなら履歴照合が選べる。

実装がここで選ぶ行動は、その実装の権力である。vCard 準拠という看板は、ローカル選択の説明を代行しない。

再番号付けで消えるのは冗長性だけとは限らない

同期例の最後で、二台しか関与していないことを利用し、グローバル文脈を簡略化する。複数のソース文脈を一つにまとめ、プロパティを再番号付けし、カードを短くする。

文書は簡略化の詳細を規定していない。示された変換は、調査に値する可能性の例にすぎない。この明示は重要である。二つの実装がどちらも「同等」と考える別々の圧縮を行う余地がある。

短いカードは配布に向く。だが、以前の CLIENTPIDMAP が示していたソース区分は薄くなる。現在の一致関係を維持できても、どの端末で値が生まれ、どの判断で統合されたかを再構成できるとは限らない。

分散システムに圧縮は必要である。イベント履歴を永久に携帯形式へ埋め込むべきではない。解決策は、サービス用カードと監査用レシートを分離することだ。旧オブジェクトハッシュ、旧ソースマップ、旧新番号対応、競合判断、出力ハッシュを別に保存する。

短いカードは現在を速く答える。長いレシートは過去を説明する。

安全な配送と正しい統合は別である

vCard 自体には認証や機密性がない。改訂 00 は S/MIME などの保護された運搬を挙げる。CardDAV の ETag は資源版を識別し、WebDAV Sync のトークンはコレクションの変更を列挙する。

これらは重要だが、意味の統合を決めない。認証された送信者でも、全フィールドの変更権限を持つとは限らない。正しい ETag を指定した書き込みでも、誤ったマージを含み得る。完全な変更一覧でも、なぜメールが削除されたかは分からない。

必要なのは層別のレシートである。配送主体と完全性、認可結果、資源版、カード対応理由、必須属性対応、裁量属性対応、競合処理、保存結果、後の利用結果を分けて残す。

電話が別人につながったとき、どの層で誤りが入ったかを追えることが、単なる「同期成功」より重要になる。

SOURCE と REV はカード全体の手掛かりにとどまる

SOURCE は情報を取り直す場所を示し、REV はカードの更新時刻を示せる。情報の陳腐化を扱ううえで有用である。

しかし、一枚のカードには企業ディレクトリ由来のメール、本人入力の携帯、別口で輸入された緊急連絡先が混在し得る。一つの SOURCE と REV では、各フィールドの由来と鮮度、マージ承認を表現できない。

だからといって vCard に全履歴を背負わせる必要はない。携帯形式は小さく保ち、重大な変更を行うアプリケーションが追加証拠を持つ。権限と結果が大きいほど、レシートも厚くする。

観測すべきは収束の内訳である

九割九分のカードが両端で一致した、という指標だけでは足りない。UID 必須マッチとヒューリスティックなカードマッチ、PID 必須マッチと裁量マッチを分ける必要がある。

さらに、CLIENTPIDMAP 不整合、ユーザーによるマージ解除、削除値、旧新マッピングのない簡略化、同期後の誤配信や不達を測る。収束率が高いまま解除率や後続失敗率が上がるなら、システムは誤りを速く複製している可能性がある。

個人の連絡帳なら可逆な提案でよい。緊急連絡先、企業名簿、規制対象通信、自動化された身元ワークフローでは隔離、二重確認、長期レシートが必要になる。

vCard4-bis の設計は、共通形式とローカル判断の境界を隠していない。運用者も隠すべきではない。

ローカル番号にグローバル文脈を与え、必要なら再番号付けする。それ自体は合理的である。ただし、番号を短くするときに説明責任まで短くしてはならない。

Sources