要約

  • RFC 9553 は言語タグから PatchObject を選び、localizations を除いた基底 Card のコピーへ全パッチを適用し、そのコピーをローカライズ版として使う。
  • 全体拒否は中途半端な変換を防ぐが、文言の公的性質、別名の承認、変更者の権限、連絡先の現在性までは証明しない。
  • 運用証跡は基底ハッシュ、選択タグ、パッチ、承認範囲、出力ハッシュ、下流利用を別々に結ぶ必要がある。

「完成した画面」が来歴を隠す

ローカライズ後の Card は断片ではない。氏名、役職、メール、住所がそろって表示される。そのため利用者は、その言語専用の完全な原本が存在すると受け取りやすい。

RFC 9553 の localizations は、RFC 5646 言語タグをキー、PatchObject を値とするマップである。処理は、タグを決定し、該当パッチを取得し、基底 Card をコピーしつつ localizations 自体はコピーせず、全パッチを適用し、必要なら language を設定する。そして結果を元 Card のローカライズ版として使う。

新しい uid は発行されない。独立した改訂履歴や事実確認も規定されない。変更されなかった値は基底から継承され、変更された値は一つのパッチ集合に由来する。

出力だけを別レコードとして保存すると、この関係が消える。後日、役職が誤っていると分かっても、基底の古さ、パッチの文言、タグ選択、キャッシュのどれが原因か追えない。再現可能な投影が、説明不能な複製になる。

原子的な成功は内容審査ではない

PatchObject のキーは、先頭スラッシュを暗黙に持つ JSON Pointer の部分集合である。末尾より前の参照先は既に存在しなければならない。配列の既存要素は置換できるが、 による挿入・削除はできない。一方のパスが他方の接頭辞になる組み合わせも禁止される。値は対象プロパティの型と制約を満たし、null で削除できるのは任意項目だけだ。

一つでも無効なら PatchObject 全体を拒否し、部分適用してはならない。この規則は、名前だけ更新され住所が失敗した混成ビューを防ぐ。

ただし成功が答えるのは構造の問いだけである。翻訳が自然か、役職が現職か、別表記が本人公認か、投稿者が電話番号を変更してよいかは判断しない。

したがって運用状態は分けるべきだ。構文解析済み、モデル適合、基底へ適用可能、送信元認証済み、フィールド変更承認済み、本人名承認済み、事実確認済み、連絡成功済みは、それぞれ異なる判定である。

パスは基底版に束縛される

RFC の例には、name 全体をウクライナ語キリル文字へ置き換えるものと、titles/t1/name だけを変えるものがある。後者は t1 の他メンバーを維持できる反面、titles、t1、name の意味が保たれていることを前提にする。

Id マップのキーは同じ JSContact オブジェクトの複数版で保持しなければならない。これは細かなパッチを安定させる。一方、同じ Id が別マップや別 Card に現れても、意味上の同一性は生じないと RFC は明記する。t1 は世界共通の識別子ではない。

基底ハッシュ A 向けに承認したパッチが、B にも構文上は適用できる場合がある。しかし t1 が別の役職を指すようになっていれば、成功した出力が古い。キーが削除されれば失敗する。無関係な項目だけ変わったなら再利用できるかもしれない。この区別には改訂方針が要る。

updated は Card データの最終変更時刻であり、変更項目、変更者、根拠、旧値、ローカライズ再審査を示さない。prodId は生成製品の識別であって署名ではない。version は登録済み JSContact モデルを選ぶ値であり、業務データの世代番号ではない。

言語タグは正式名称を認証しない

RFC 5646 のタグは言語・文字・地域を表現できる。RFC 9553 は「言語タグを決定する」ことから始めるが、製品の言語交渉をすべて定めない。地域タグのフォールバック、文字体系の優先、主言語へ戻す条件は製品方針である。

タグが正しくても、文字列の地位は分からない。組織名の別表記は正式名称、定着訳、音写、編集上の便宜、あるいは捏造かもしれない。人名の別文字表記も、本人が使う原名と機械的な置換では性質が違う。

PatchObject は代替値を運べるが、それを正式別名へ昇格させない。人や組織の識別文字列を変えるなら、公的な多言語資料、本人承認の別名、審査済み転写規則を添えるべきだ。証拠がなければ、主張できるのは「この表示候補がある」までである。

住所や役職も同じだ。構成要素の順序を変えただけか、行政区分を誤訳したかは型では分からない。役職の訳語が権限階層を変えてしまうこともある。

攻撃者の表示も自然になり得る

RFC 9553 の Security Considerations は、連絡先情報が本人性、所在、資格情報、雇用、関心、社会関係を明らかにし得るとする。盗聴、リプレイ、挿入、削除、改変、経路上攻撃を挙げる。

さらに、他人の名前を使いながら攻撃者自身の連絡先を入れるなりすまし例を示す。流暢にローカライズされた詐欺は、粗い原文より信用されやすい。自然な敬称や地域形式が、電話番号やメールの支配者を確かめる動機を弱める。

現実の結果を生むシステムは、受信データを認証し、変更が権限を持つ主体から来たことを確認しなければならない。同時に RFC は、自身がデータ形式だけを定義し、API・保存・伝送の安全は別層の責務だと線を引く。

TLS は配送元サービスを示せても、そのサービスが全フィールドを書き換えてよいとは限らない。署名はパッチ作成者を示せても、本人の別名承認を示さない。スキーマ検査は不正なポインタを止めても、型の正しい虚偽を見抜けない。

IANA 登録は語彙の権威である

RFC 9553 は JSContact 1.0 を登録し、バージョン、プロパティ、型、列挙値の IANA レジストリを作る。Since Version と Until Version により、どのモデルで要素が有効かを共有できる。

これは相互運用のための権威であり、個別データの真偽を決める権威ではない。プロパティが登録済みでも、役職が現職とは限らない。URI が妥当でも本人管理とは限らない。

「JSContact として有効」は、指定モデルとレジストリ時点に対する判定として表示すべきだ。それを「本人確認済み連絡先」と言い換えると、形式統治を本人認証へ誤って拡張する。

小さな系譜記録で十分である

必要なのは言語ごとの巨大な台帳ではない。基底 Card の uid、モデル版、内容ハッシュ、業務世代；タグを選んだ要求や規則；PatchObject の原文、ハッシュ、出所、権限範囲；全体検証結果；出力ハッシュ、時刻、下流利用を保存する。

氏名や組織名を変える場合は別名根拠を加える。電話・メール・住所が自動処理を動かすなら、その行為と結果を記録する。画面表示に成功しただけなら、配信や到達を主張しない。

基底が更新されたとき、この系譜から「影響なし」「要再審査」「適用不能」を分けられる。言語ごとのコピーを独自編集して収束を祈る必要はない。

ローカライズの目的は、同じ対象を違う読者へ正確に届けることだ。その価値は、何を継承し、何を替え、誰が承認し、実際に何が起きたかを説明できるときに最大になる。

出典