要約

  • RFC 2122が定めたのはデータ物体ではなく対話型マルチメディアサービスのURLであり、VEMMIクライアントは通常、ポート575でTCPセッションを継続した。
  • URLはサービスと名前付きパラメータを運べたが、ユーザー名とパスワードは運べない。ブラウザ対応、認証、VEMMI_Openは後続の別段階だった。
  • application/vemmiは独立した物体転送を担った。operative objectは実行プログラムになり得るため、受信、承認、実行、安全な結果は別の証拠を要した。

サービスを指すアドレス

1997年3月にProposed Standardとして刊行されたRFC 2122は、ビデオテックスとマルチメディア検索のための拡張マンマシンインターフェースVEMMIにURL schemeを与えた。本文は、このURLがデータ物体ではなく、対話型サービスを指定すると明記している。

形式はvemmi://<host>:<port>/<vemmiservice>;<attribute>=<value>。ポートを省けば575、サービス名や属性値も必要に応じて付ける。安全上、クライアントはURL中の別ポートを無視してよい。しかし、これは起動指示の記述にすぎない。名前解決、listen、サービス提供、パラメータ受理を証明しない。

VEMMIは通常、利用中ずっとTCP/IP接続を保ち、物体の管理や操作報告に用いた。Webは待ち合わせ場所であり、実行環境そのものではなかった。

クリックの後に対話が始まる

接続後、サーバーはservice:、username:、password:を求められた。クライアントはURL、設定、または利用者への質問から答える。VEMMI_Openを受けるまでは、端末はビデオテックスまたはtelnet互換の標準モードに留まる。

ユーザー名とパスワードをURLに入れることは禁止された。サービス選択と本人確認は同じ記録ではない。200 OKや401 Unauthorizedの例も、実測結果ではなく分岐の説明だ。リンク選択、handler起動、TCP接続、認証、セッション開始はそれぞれ別の受領証になる。

未対応ブラウザはサービス以前で止まる

対応はブラウザ内蔵または関連ソフトウェアで提供できた。未対応なら、未知schemeとして拒否するブラウザもあれば、相対URLと誤解して元ページのHTTPサーバーへ送り、not foundになるものもあった。HTMLにvemmi://があるだけでは、端末側handlerすら証明できない。

RFCはクライアントの別配布、誤った相対要求の検出、Accept: application/vemmiによる推測を提案したが、普及率は示していない。仕様上の案を導入実績に読み替えてはならない。

物体転送は別の役割

application/vemmiはHTTPやメールでVEMMI物体を送り、継続セッションを開かず取得するために使えた。VEMMI URLを記したテキストを包む場合もある。schemeはサービスへの道を起動し、media typeは転送・解読する物体を示した。

IANAは現在もvemmiを恒久URI schemeとして、application/vemmiとポート575も登録している。これは名前空間の事実であり、保守中のソフト、稼働サービス、通信量、相互運用、採用を示すテレメトリーではない。

実行には独自の同意が要る

metacode objectは命令列を、operative objectはクライアントで動く実行プログラムを含み得た。RFCは自動実行を止めるか、少なくとも事前承認を求めるよう強く勧めた。

配送は実行権限ではない。型の確認、download、decode、承認、実行、結果は別の制御点である。ユーザー名とパスワード方式も安全でなく互換性のためと記された。これは1997年の歴史的評価で、現代の推奨ではない。

RFC 1738はschemeごとにアクセス方法が異なる余地を用意した。RFC 2122は、Webページが状態を持つruntimeへ引き渡す具体例である。Running-Code Primacyの視点なら、文書や登録が稼働実装の権威を借りることを防げる。

正確な履歴は、命名、認識、引渡し、接続、選択、認証、開始、配送、承認、実行、観測という列で残すべきだ。「リンクが動いた」では、RFC 2122が見せた境界そのものが消える。

出典