要約

  • RFC 9982 は JSContact 2.0 の Card で uid を任意にし、UID のない vCard を v2 へ変換する際に識別子を新設することを禁じる。
  • 識別子はモデル内でカードを参照可能にするが、実在する主体、現在の関係、出所、同意、統合権限を単独では証明しない。

以前の JSContact はすべての Card に uid を求めていた。同期には安定した取っ手が必要であり、この設計は理解しやすい。しかし vCard の UID は任意である。UID のない vCard を旧版 JSContact に変換すると、実装は値を生成しなければならなかったが、別実装や同じ実装の再変換で同じ値になる保証はなかった。その一時的な値が members や relatedTo に使われると、変換の都合がカード間の関係事実に変わってしまう。

RFC 9982 の答えは、カードの内容を捨てずに参照可能性を限定することだ。v2 では uid のない Card は有効である。ただし members のメンバーにも、別の Card の relatedTo の相手にもできない。これは「この連絡先は存在しない」という判断ではない。この記録には、機械可読な関係を張るために必要なアンカーがない、という限定された判断である。

変換時の規律が重要である。入力 vCard に UID がなければ、2.0 以上への変換で uid を生成してはならない。1.0 では旧規則が生成を要求したが、方式は実装依存で、反復安定性の推奨も相互運用の曖昧さを消せなかった。バージョンは単なる表示ラベルではなく、どの不在を欠陥と呼ばず、どの関係を作らないかを定める境界になる。

uid がある場合も過大評価してはならない。それは Card の文字列であり、署名、法的氏名、本人確認、アカウント支配、関係への同意、書換え許可ではない。JSCOMPS の IANA 登録は変換パラメータの台帳を正確にする。変換後のカードが元の意図や現在の関係を忠実に表すことまでは保証しない。CardDAV や JMAP Contacts が同期のためにキーを必要とすることと、RDAP が同じキーを必要としないことも、プロトコルの要求と主体の真実を混同しない理由になる。

Heng Lu の最小共通仕様という見方では、この余白は欠点ではない。形式は交換を可能にするが、主体同定、関係確定、統合、更新という局所的で可逆性を要する判断を代行しない。