要約

  • 草案はChangeSetのポーリング、部分住所による対象レコードの抽出、将来のasOf時点を使った置換レコードの事前検証を定義する。
  • 将来応答は回答時点でサーバーが知る計画にすぎず、NO-CACHEであり、生効前に変わり得る。サービス利用時の同時点LoST照会を代替しない。
  • 通知、ストリーム継続、事前検証、ローカル準備、切替実行、通報時マッピング、位置伝達、PSAP経路、応答結果を別々の受領証として残す必要がある。

住所の効力が変わる瞬間を、物理移動と混同しない

ある地区が午前零時に市へ編入される。建物も端末も回線も移動していない。それでも零時前に正しい住所と、零時後に正しい住所は異なり得る。PIDF-LOのA3など行政要素が変わり、Location Information Serverは旧レコードを退役させ、新レコードを有効化しなければならない。

現行Internet-Draftは、この既知の時刻を持つ変更を事前に扱う。RFC 5222のLoSTは位置とサービスからサービスURIを求め、市民住所の要素を検証できる。RFC 5139は住所表現を与える。新案はPlannedChangePoll、GetChangeSet、Versionsを加え、クライアントがサーバーの知る変更列を追えるようにする。

ChangeSetにはID、有効時刻、部分位置の集合が入る。クライアントは部分位置を自分の行と比較し、影響候補を選び、置換行を作る。さらにasOfで将来時点の妥当性を問い合わせられる。revalidateAfterは次に検証すべき時刻の助言になる。

これは準備の仕組みであって、未来を執行する仕組みではない。

NO-CACHEは設計上の警告である

草案は、将来のasOf応答をサーバーの現在の理解と位置づける。未計画の変更や新しい計画が後から入れば、同じ将来時刻への二回の照会が違う答えになる。応答のmappingにはexpires="NO-CACHE"が必要で、クライアントはその値が将来も変わらず有効だと仮定してはならない。

実際にサービスへ接続するときは、その時点でLoSTを使うことが求められる。この一線によって、事前計画、データベース切替、実通報の経路が別の事実になる。

NO-EXPIRATIONも永久保証ではない。サーバーが現在把握する計画変更がなく、特定の再検証時刻を勧めないという意味に限られる。草案はポーリングがあっても定期再検証を残している。

RFC 6443が描く緊急通報は多段である。位置を取得し、LoSTで対応先を求め、位置情報をシグナリングに載せ、プロキシや緊急ルーティング機能を通り、PSAPが受け取る。RFC 6881は通報時の位置とLoSTマッピングの更新を試み、間に合わない場合のキャッシュ利用も規定する。昨日の事前検証は、今日どの分岐を通ったかを証明しない。

ChangeSet IDは一つのサーバーとの会話位置である

クライアントは最後のIDを保存し、その後の変更を求める。ID文字列自体が順序を示す必要はなく、順序はサーバーが管理する。IDを失えば、クライアントはサーバーがまだ保持するChangeSetから復旧するしかない。

Security Directorateのレビューは、この境界を問い直した。IDはサーバーごとの名前空間なのか。複数サーバーで衝突したらどうするのか。クライアントは権威ごとにキューを持つのか。同じ日付について権威が一致しない場合、どの状態を採るのか。さらに、本文が後続ポールに旧IDを要求する一方、OpenAPIにはその入力が見当たらないようだと指摘する。

したがって、カーソルが証明できるのは限定的である。特定サーバーの保持列の中で、クライアントがどこまで見たかは示せる。全権威の合意、欠落なし、ローカル適用完了までは示せない。

Operations Directorateのレビューはスキーマにも同じ構造を見る。RFC 5222のRelax NGを権威ある定義として残しつつ、扱いやすいXML Schemaを非権威の代替として拡張の土台にする。便利な検証器に通ったことを、等価性の証拠なしに権威ある適合へ拡張してはならない。

切替は九つの状態を一枚の緑色に潰さない

通知の受領証には、発行サーバー、ID、有効時刻、部分位置、対象行を残す。ストリーム受領証には、サーバー範囲、前カーソル、戻り列、保持期間、欠落やリセットを残す。将来検証には、照会時刻、asOf、入力行、応答、NO-CACHEを残す。

ローカル準備は、置換行の生成、競合、承認、実行予約を記録する。有効時刻には別の証拠が必要だ。旧行が実際に停止し、新行が実際に有効となり、失敗が隔離され、ロールバックが残ったかを観測する。

実通報では現在から再び証拠を取る。端末が得た位置、当時のLoST mapping、PSAP URI、伝達された位置オブジェクト、プロキシとESRPの経路、PSAP受信、呼成立、運用応答である。連続したワークフローだからといって、上流の成功が下流の成功を署名することはない。

各システムは自分が所有する状態だけを証言する。この最小権限こそ、文書上の予定を実行可能な現実へ移すときの安全装置である。

まだ評価中の提案である

調査締切時、IESG議題は第18版を9月24日のtelechatに載せていた。DatatrackerはIESG Evaluation、3件のDISCUSS、追加投票の必要、未解決のIANA XML登録問題を示していた。安全・運用レビューはいずれも問題ありとした。これは承認済みRFCでも、実装実績でも、相互運用試験でもない。

本稿は採否を予測しない。文書状態が変わっても残る運用原則だけを扱う。予定は予定の証拠、切替は切替の証拠、緊急結果は結果の証拠で評価しなければならない。

情報源

一次資料：現行Internet-Draft、IESG議題、Security Directorateレビュー、Operations Directorateレビュー、RFC 5222、RFC 5139、RFC 6443、RFC 6881。