要約

  • RFC 10050のプロファイルは、登録済みのJSContactプロパティ、型、値を制限する、名前付き・版付きの集合である。基礎仕様より厳しくできるが、緩めることはできない。
  • Cardの中には汎用のプロファイル宣言がない。一つのカードが複数のプロファイルに同時適合し得るため、外側のプロトコルが名称と版の伝達方法、選択、追加条件を定める。
  • IANA登録簿は名称と版の履歴を固定するが、登録は内容の安全性や用途適合性の認証ではない。運用上の受理責任はプロトコル設計者と導入者に残る。

障害調査で「バリデーション成功」という一行だけが残っていたら、何が成功したのかを特定できるだろうか。JSONとして読めたのか、JSContactとして妥当だったのか、特定プロファイルに適合したのか、それとも業務プロトコルが受理したのか。同じ緑色の表示でも意味は違う。

2026年9月にProposed Standardとして公開された RFC 10050 は、この違いを設計上の境界として扱う。目的は別の連絡先形式を作ることではない。汎用的なJSContactの使い方を狭め、その狭め方に再現可能な身元を与えることである。

狭めるための規則

RFC 9553 の Card は多様な利用を想定する。個々のサービスは、任意プロパティを必須にしたり、合法なプロパティを禁止したり、型や値の範囲を限定したりしたい。プロファイルはそのための制約集合だ。

ただし、方向は常に制限側である。基礎仕様で不正なものを、プロファイルが正当化することはない。したがって検査結果は段階ごとに保つ必要がある。まずJSContactの妥当性、次に選択されたプロファイルへの適合、最後にプロトコル固有の妥当性である。

プロファイルの身元は、大文字小文字を区別する名称と正の整数の版の組で決まる。登録後、その名称・版に対応する内容は差し替えられない。変更はより大きい版番号で登録し、旧版も残す。

これは過去の判断を守る仕組みだ。ログに「版2」とあれば、版3の登場後も同じ制約を参照できなければならない。参照先を上書きすれば、保存済みメッセージも相互運用試験も、何を根拠に判定されたか分からなくなる。

プロパティ集合は木の奥まで続く

実装上の要点は再帰性にある。プロパティは入れ子のオブジェクトを持ち、許可された型がさらに別のプロパティを導入することがある。RFC 10050の「サポートされるプロパティ」は、到達可能な構造を再帰的にたどった閉包として考えなければならない。

最上位だけの許可リストでは、下位の禁止要素を見逃す。一方、文書に直接列挙されたもの以外を全て拒む実装は、許可された型から合法的に到達する要素まで落としてしまう。RFC 6901 のJSON Pointerは場所を正確に指すが、木全体を走査した証明にはならない。

運用記録には、基礎仕様、プロファイルの名称と版、検証器の版、たどったプロパティと型の辺、失敗規則を残すべきだ。単一の真偽値では、検査の深さが消える。

カード自身にプロファイル名を書かない理由

RFC 10050は、Cardに普遍的なプロファイル名フィールドを追加していない。名称と版の運び方も一つに固定しない。利用プロトコルが定めるからである。

一枚のカードは複数プロファイルの交差部分に入り得る。内部ラベルを一つだけ置けば不完全になり、複数置いても今回どれが合意されたかは分からない。そもそも送信者の宣言は受信者の検証結果ではない。交渉、許容版、エラー処理、追加制約を知るプロトコルが、適用する身元も運ぶべきである。

したがって「有効」は一種類ではない。JSContactとして有効、指定プロファイルに適合、当該プロトコルで有効、という三つを別々に記録する。プロファイルで許されたプロパティをプロトコルが禁止すれば、二つ目が成功して三つ目が失敗する。

登録は審査印ではない

新規登録は RFC 8126 のSpecification Requiredに従い、参照更新はExpert Review、変更管理者はIETFとなる。指定専門家は、識別子の一意性と構文、既知のプロパティと型、仕様の安定性、新版番号の増加などを確認する。

一方で、プロファイル内容そのものを評価する義務は負わない。登録はセキュリティ認証でも、プライバシー承認でも、業界適合証明でもない。連絡先情報の最小化が十分かどうかは、RFC 9553の注意を踏まえ、採用する側が判断する。

本調査時点の IANA JSContact登録簿 では、Profiles欄に登録がなく、指定専門家も未割り当てと表示されていた。ページの最終更新日は2026年5月28日で、参照はまだInternet-Draftだった。9月公開のRFCより前の時点である。これは更新遅延を断罪する材料ではなく、日付付きの観測にすぎない。

ただし、運用者が自分の根拠を保存する理由にはなる。名称、版、参照仕様のコピーまたはハッシュ、取得日時、基礎JSContact版、検証器版、再帰閉包の結果、プロトコルが選択を運んだ方法、追加規則を一つの保管記録にまとめる。将来ページが変わっても、過去の受理判断を再現できる。

出典