要約

  • Uniform Resource Agentは、起動データ、対象、経験情報、活動スクリプト、応答フィルターを持つ永続的な活動仕様であり、共有、変更、再実行を可能にした。
  • 実行はURAgencyの仕事だった。型を具体的な実装へ対応させ、ランタイム依存を満たし、ローカルまたは遠隔の対象を起動し、返答を解釈した。
  • したがって、仕様が残っていることやプログラムが起動したことだけでは、入力の許可、意味の同一性、安全な実行、再現性、目的の達成は証明できない。

RFC 2016が分離しようとしたのは「何をしたいか」と「どの仕組みで行うか」である。メーリングリストへの登録や複数サービスの検索は活動であり、URL、プロトコル、スクリプト、特定サイトはその時点の手段にすぎない。クライアントに両者を固定すると、サービスの変化がそのままアプリケーションの破損になる。

URAは活動を保持するオブジェクトだった。共通の仮想構造には六つの要素がある。ヘッダーは型を示し、activation dataは呼び出し時に必要な値を示す。targetsはURLまたはURNで資源を指す。experience informationは前回の実行日や発見済みURLを残せる。activity scriptは条件、順序、予定を記述し、response filterは返答を整形したり関連性を判定したりする。

この構造は意思決定の場所も示す。入力欄は、その値を使う権限までは保証しない。対象は近隣ホスト、ミラー、遠隔URAgencyへ差し替えられる。経験情報は効率化と同時に古い前提を持ち込む。フィルターは部分的な一致やエラーページを成功に見せる可能性がある。

仕様書の外側に実行環境があった

URAgencyは処理できるURA型を表明し、各実装と仮想構造の間を変換し、起動方法を知り、必要な実行環境を用意した。Pascalのバイナリと解釈型スクリプトが似た活動を表しても、必要なライブラリや信頼境界は異なる。活動の可搬性はランタイムの等価性を意味しない。

遠隔起動では、URAgency自体がtargetになり、URAが別のURAを呼び出し、上位URAが複数の処理を編成できた。委任が増えるほど、認証情報を誰が扱うか、対象を誰が置換するか、どの環境が生データを見るか、各段階が何を完了とするかが重要になる。

Silkの試作はその具体例である。Tclで書かれたURAをデスクトップ画面から起動し、活動インスタンスを保存して値を入力できた。例示コードは特定サービスへHTTP要求を送り、HTMLを正規表現で解析する。コメントは不十分なエラー報告も認める。これは試作の証拠であり、普及の証拠ではない。

人向けの表示は壊れやすい入力だった

RFCは、人には小さく見える表示変更でもソフトウェア解析を破壊し得ると明記した。DaigleとMazzucatoの同時期の論文も、HTMLへの正規表現依存を不安定な接点として扱う。機械向け入口やサービス提供者が保守するURAは改善策だが、保存済みオブジェクトの永続的正しさを保証しない。

起動記録は開始を示すだけである。プロセス終了は一つの実行環境が停止したことを示すだけである。同じURAを再実行しても、別のミラー、更新された依存、変更されたページへ到達するかもしれない。生の返答を失えば、フィルターが誤ったのかサービスが変わったのか後から区別できない。

RFC 2016は1996年10月、Legacy streamのExperimental文書として公開された。現代AIエージェントの直系祖先や広く採用された標準と呼ぶ根拠はない。歴史的な価値は、活動を運べるようにしたことで、逆に実行権の所在を見えるようにした点にある。

情報源