要約

  • RFC 9695 の haptics/* は触覚サブシステムへ向かう共通の分類であり、個々の受信機が全エフェクトを理解し、同じ感覚を安全に再現したという証明ではない。
  • 検証可能な完了には、入力ハッシュ、無視した値、基準機器から実機への変換、許可と制限、アクチュエーター命令、停止・中立状態までを結ぶレンダリング受領書が要る。

触覚コンテンツの「機器非依存」は、出力の機器同等性を意味しない。RFC 9695 は haptics をトップレベル媒体型として登録し、最初のサブタイプとして IVS、HJIF、HMPG を置いた。トップレベル型は触覚サブシステムと関連ハードウェアが必要な内容だと示し、サブタイプが正確な表現形式を示す。

この分業は配送には強い。しかし、登録名は現場のアクチュエーター数、配置、周波数帯、力の上限、温度チャネル、時間分解能を知らない。ファイルが正しい入口へ届いた時点で、出力の決定権はローカルな能力と方針へ移る。

基準機器は変換の出発点にすぎない

IVS は XML を用いる機器非依存の交換形式である。同じ記述を複数の製品へ運べる一方、RFC はすべての機器がすべてのエフェクトをレンダリングできるわけではないと明記する。非依存性は不足するハードウェアを補わない。

JSON ベースの HJIF とバイナリーの HMPG は、時間的・空間的な触覚と身体部位を表現できる。基準機器の記述も含められ、レンダラーはそれを実機へ適応する。この適応が、抽象的な作品を物理命令へ翻訳する場である。

基準機器の空間的な波を、二つのアクチュエーターしか持たない実機へ写す場合を考える。順序を保った二つのパルスにすることも、単一の振動へまとめることも、表現不能として落とすこともできる。出力範囲が狭ければ振幅を圧縮し、熱チャネルがなければ温度エフェクトを削る。いずれも入力形式の受理とは両立する。

したがって必要なのは「デコード成功」ではなく、エフェクト差分である。要求された一覧、パーサーが理解した一覧、実機へ適応した一覧、安全方針後に命令された一覧を比較する。統合、移動、縮小、クリップ、削除の各判断に理由を付ける。同じファイルが二台で違って感じられた時、差分が説明を可能にする。

Apple Core Haptics の公式資料は、このローカル層の例を示す。瞬間的・連続的イベント、強度や鋭さのパラメーター、パターンプレーヤー、エンジンがある。アプリはハードウェアが触覚に対応するか確認する必要があり、AHAP では省略したパラメーターに既定値が使われる。これは Apple が RFC 9695 を実装するという証拠ではない。能力検出と既定値が結果の一部だという実装上の例である。

未知サブタイプは「何もしない」と同義ではない

RFC 9695 は、認識できない触覚サブタイプを application/octet-stream として扱うべきだとする。RFC 2046 に沿う安全側の分類であり、未知のバイト列へ勝手に形式の意味を与えない。

同時に、実装が未知サブタイプを触覚サブシステムと関連ハードウェアへ渡すことも認める。上位アプリが知らない将来形式を、下位サービスやプラグインが知る場合があるからだ。拡張性のための余白だが、証拠上は二つの経路を分けなければならない。

媒体層では、どのレジストリーに基づき、サブタイプを認識したか、汎用バイナリーへフォールバックしたかを記録する。アプリ層では、保存したか、デコーダー探索を行ったか、触覚サービスへ渡したか、形式確定前の物理出力を禁止したかを記録する。「octet-stream になった」だけでは、ハードウェアから隔離されたとは言えない。

RFC 6838 は媒体型の登録手続きを定め、RFC 9694 はスラッシュ左側の新しい名前に必要な基準を扱う。そこでは共有名前空間が主題である。本稿では、名前空間が正しく仕事をした後に残るローカルな翻訳を扱う。

部分的に理解して処理を続ける

パラメーターには、コンマで区切った複数のサブ値を含められる。処理系がパラメーター自体を理解していても一つのサブ値を知らない場合、RFC 9695 は未知値を無視し、認識した値で処理を続けるよう求める。

この規則は、将来の拡張が古い実装を全面停止させるのを防ぐ。一方で、送信者が複数値を一体の制約と考え、受信者が選択肢だと考えれば、成功の意味がずれる。未知値が身体部位、機器能力、モダリティー、制限を表していたなら、捨てた後のエフェクトは元の依頼と同じではない。

受領書には、生の値、認識した値、無視した値、採用した既定値と、その結果のデコーダー設定を残す。実装バージョンも不可欠である。更新により未知値が既知になれば、同じ入力ハッシュでも出力経路が変わるからだ。

「媒体」はソフトウェアと身体の安全を代行しない

登録情報は IVS、HJIF、HMPG を実行コードではなく媒体として分類する。しかし XML、JSON、バイナリーの構造はパーサー、メモリー、ユーザー空間のサービス、場合によってはドライバーやカーネルに近い経路を通る。記述データであっても、脆弱な実装に対する入力になり得る。

もう一つの安全性は物理出力にある。触覚は振動だけでなく、運動感覚の力、温度、質感に関わる。RFC 9695 は、熱・運動感覚機器の制限が管理されなければ負傷し得ると警告する。ファイルの検証は、力、温度、振幅、継続時間、変化率、反復回数の制限を証明しない。

ソフトウェア安全と物理安全を別々に評価する必要がある。前者は構造検証、資源消費、隔離、デコーダー、ドライバーを対象とする。後者は実機能力、利用者同意、ローカル制限、停止経路、中立状態、累積暴露を対象とする。どちらか一方の合格を、もう一方へ転用してはならない。

W3C Vibration API は、文書の可視性や Permissions Policy によって振動要求を制限できる例を示す。この API は RFC 9695 の三形式と同一ではない。ここで重要なのは、妥当な要求がコンテキスト方針で拒否され得ること、そしてその拒否を形式エラーやハードウェア不在と区別することである。

最後の証拠は中立状態である

証拠鎖は入力のハッシュと宣言型から始まる。次に、現在の IANA 媒体型レジストリー、サブタイプ認識、フォールバック、パラメーター解釈、デコーダー結果を結ぶ。さらに基準機器と実機能力を比較し、適応差分を作る。

その後にアプリ、OS、利用者、安全制限の判断があり、最終的なアクチュエーター命令がある。再生終了だけでなく、停止命令と中立位置・中立温度への復帰確認を完了条件にする。それでも命令ログは物理測定ではなく、物理測定も利用者の感覚そのものではない。各層には固有の測定方法が必要だ。

RFC 9993 は MPEG-I 触覚の RTP ペイロード、断片化、集約、SDP パラメーターを定め、haptics/hmpg を更新する。正しい単位を再構成することは輸送の証拠であり、本稿の適応・作動の証拠とは別である。

Lu Heng の最小初期仕様という考え方は、共通層を型名、サブタイプ、パラメーター構文、基本フォールバックに絞る。将来の能力、採用、同意、安全制限はローカルに残す。ただしローカル判断は不可視であってはならない。現実の層を分ければ、登録、ヘッダー、解析、適応、命令、測定、感覚は互いの証明を借りられない。稼働コード優先とは、この実機の受領書を仕様上の可能性より上位に置くことである。

情報源