要約

  • ECRIT の現行草案は、順序付きの予定変更ポーリング、asOf による将来時点の検証、revalidateAfter による再検証の助言を LoST に加える。クライアントは影響候補を絞り、発効前に代替レコードを準備できる。
  • 同じ将来日時を指定しても、問い合わせた時刻が違えば回答は変わり得る。回答はサーバーが現在知る将来像であり、その後のマッピングやクライアントでの実行を保証しない。
  • 準備時の記録と発効時の記録を別々に残す二段階の検証受領記録が必要である。これは Daniel Kade の編集上の提案で、IETF の要件ではない。

行政上の日付が住所を二つに分ける

草案は、市や町による区域編入を例に挙げる。発効前には空欄だった行政区分に、発効後は編入先の自治体名が入ることがある。道路の改称や番地変更でも、同じ場所について旧表現と新表現が生じる。

Validation of Locations Around a Planned Change の第18版は、ECRIT ワーキンググループの有効な Internet-Draft である。まだ作業中であり、RFC ではない。実装や採用、現実の事故を示す資料でもない。

RFC 5222 が定める LoST では、クライアントが所在地とサービス識別子を送り、サーバーがサービス URI などを返す。住所要素の妥当性を確認する機能もある。RFC 5139 は、草案の例で使われる行政区分を含む市民住所形式を定義している。

予定の通知がなければ、多数の所在地を持つクライアントは全件を定期的に再検証するしかない。間隔が長ければ切替に遅れ、短ければクライアントとサーバーの双方に負荷がかかる。草案は、変わりそうな範囲だけを知らせ、発効日を想定した検証を可能にする。

ただし、来週を指定した今日の回答は、来週の観測ではない。これは語法の問題ではなく、証拠の成立時点を決める根本的な境界である。

三つの時計を一つの状態に畳まない

第一の時計は予定変更フィードにある。別の REST/JSON インターフェースが、対応版の取得、ポーリング、ChangeSet の取得を提供する。ChangeSet は順序を持つ ID、発効時刻、部分所在地の配列を含む。クライアントは最後の ID を保持し、その後を尋ねる。

第二は asOf の時計である。findService に日時を付けると、サーバーは問い合わせ時点の知識に基づいて、その日時までに有効になると考える状態を返す。現在以外を対象にした応答では asOf を返し、各マッピングを NO-CACHE としなければならない。

第三は再検証の時計である。revalidateAfter は次に検証してよい目安を伝える。NO-EXPIRATION は、結果に影響する予定変更をサーバーが今は認識していないという表明にすぎない。永続性の保証ではない。

ポーリングは新しい通知を、asOf は現在の将来予測を、revalidateAfter は次の確認時期を扱う。行政行為の完了、ローカル DB への反映、現在のサービス解決、通信の到達は別の事実である。

一つの「検証済み」表示にまとめれば、サーバーが見ていない実行まで証明したように見える。簡便な表示が、観測範囲を越えた権限を作ってしまう。

部分所在地は影響候補を探す道具

ChangeSet は、全住所を列挙する代わりに部分所在地を使う。名前空間、要素名、値の組をクライアントのレコードと比較し、提示された組がすべて一致すれば、そのレコードは影響を受ける可能性がある。省略された要素は比較しない。

行政区域全体を道路や番地に関係なく選んだり、一本の道路を全番地について選んだりできる。これは候補抽出を効率化する設計で、最終判断を代行する設計ではない。

クライアント側の証拠には、ChangeSet だけでなく、DB スナップショット、照合規則、候補レコード、除外、例外を残す必要がある。件数だけでは、区域が広がったのか、データが訂正されたのか、照合実装が誤ったのかを後から区別できない。

Lu Heng の最小初期仕様と局所的な将来判断は、この役割分担を読む手掛かりになる。共通層は相互運用に必要な厳密な形式を持つ。後の採否や運用時刻まで中央の形式が決める必要はない。

将来の回答は変えられるから役に立つ

草案は、同一の将来 asOf を指定した二回の問い合わせが異なる結果になり得ると明記する。サーバーは計画内外の変化を後で知ることがあり、同じ所在地への将来の回答を保証しない。

区域編入の延期、道路一覧の修正、データ到着の遅れ、別の変更の追加は、いずれも初回予測を変える理由になる。早い予測を固定すれば、運用計画はきれいに見えても現実から離れる。

NO-CACHE は、その訂正可能性をプロトコル上の扱いに反映する。さらに、サービスへ連絡する必要が生じた時点で、クライアントはその時の LoST を使うことが期待される。将来の住所検証と現在のサービス探索は同じ処理ではない。

ECRIT の憲章は、所在地とルーティング情報を使って適切な緊急応答機関との通信を可能にする仕組みを対象にする。同時に、地域や法域を越えて利用でき、単一の中央機関を必須としない構成を求める。住所が妥当だから通信が成功した、あるサーバーが予測したから全クライアントが反映した、という二つの飛躍を避けなければならない。

Lu Heng の「現実こそが成果物であり、主張ではない」という編集原則に従えば、回答には必ず観測時刻と対象時刻を添える。未来形を完了形に変えるのは、後日の観測である。

順序があっても連続性は失われる

クライアントは数分ごとにポーリングし、直前の ChangeSet ID を使うことが想定される。新しい ID が返らなければ、その ID がサーバーの現在知る末尾だと分かる。

新規クライアントや ID を失ったクライアントは、ID なしで問い合わせ、サーバーがまだ保持する ChangeSet を受け取る。しかし保持期間は無限ではない。草案は、変化の少ない地域なら十二か月、変化の多い地域なら三か月という例を示す。

停止が保持期間を越えた場合、残存列は順序正しくても履歴は欠けている。クライアントは不連続を記録し、現在の全体検証などで新しい基準点を作り、別の追跡エポックを始めるべきである。

空の応答は、過去の ChangeSet を処理済みであることや、予定外変更がないことを証明しない。示すのは、送った ID とサーバーの現在リストの関係だけである。

Lu Heng の Policy Mirror がいう台帳と玉座の違いはここにもある。台帳が観測した範囲では尊重し、観測していない下流の行為まで語らせない。

準備と発効を二段階で受領する

準備記録には、サーバー識別、インターフェース版、ポーリング時刻、前回 ID、返された ID、発効時刻、部分所在地を含める。ローカル DB のスナップショット、照合規則、候補数、例外も必要である。検証要求の所在地とサービス、asOf、回答、revalidateAfter、キャッシュ状態、参照した草案版と時計を結ぶ。

発効記録には、運用者が採用した時刻、旧レコードの停止、新レコードの有効化、同時点での再検証、準備回答との差、延期・失敗・ロールバック、完了責任者を含める。

これは本稿の編集提案であり、IETF 草案の要件ではない。所在地の詳細は保護しつつ、公開面では件数、時間帯、ChangeSet 参照、未解決例外を示すことができる。ハッシュは二つの面を結べるが、内容の正しさを自動的に証明はしない。

実際の回答が準備時と異なるなら、どちらも残す。前者は当時の合理性を、後者は発効時の現実を示す。一方を上書きすれば、組織は判断の経緯か現在の事実のどちらかを失う。

再検証間隔には所有者がいる

草案は、再検証周期を鮮度、サーバー負荷、元データの安定性、ポリシーの均衡として扱う。安定地域では六か月以上、成長の速い地域では 20～30 日という例があるが、普遍的な期限ではない。

サーバーは負荷とデータ更新を知り、クライアントは古い情報の損失を知る。revalidateAfter は助言であり、最終的なリスク判断はローカルに残る。助言から外れるなら、決定者、理由、範囲、見直し条件を記録する。

周期が長過ぎれば無効なデータが残る。短過ぎるポーリングは他の LoST 処理に影響し得ると、草案のセキュリティ節は指摘する。鮮度と可用性は同じ容量を消費する。数字だけでなく、誰がどの根拠で選んだかが統制の対象になる。

証拠が届く範囲

準備記録は、一つのクライアントが一つのサーバーから ChangeSet を取得し、定義したスナップショットに照合し、将来検証を受けたことを示せる。発効記録は、そのクライアントが後に何を有効化し、再検証で何を得たかを示せる。

それでも、行政行為の法的正当性、全サーバーの一致、その後のマッピング不変、通信の到達までは証明しない。それぞれ別の層と証人を必要とする。

行政機関が境界を変える。LoST サーバーがデータを表す。クライアントがローカル状態を切り替える。現在問い合わせがサービスを返す。通信系が接続を試みる。これらの動詞を分けることが、説明責任を弱めるのではなく、正しい主体に戻す。

出典