プロンプトとシナリオ
あなたのチームは、ダウンロード、ライブメディア、デバイス間転送を通じて触覚トラックを交換する必要があります。既存のaudio、video、applicationタイプは、そのセマンティクスを部分的にしか表現できません。RFC 9694を使用して、新しいhapticsトップレベルメディアタイプが正当化されるかどうかを評価し、サブタイプ、コンテンツネゴシエーション、未知の実装、進化、およびセキュリティ境界について説明してください。
面接官が評価している点
- MIME文字列を完全なプロトコルとして扱うのではなく、トップレベルタイプ、具体的なサブタイプ、パラメータ、ファイル形式を明確に区別できているか。
- 明確なスコープ、少なくとも1つの有意義なサブタイプ、公開仕様、相互運用性、およびIANA登録要件を適用できているか。
- 未知のタイプ、古いクライアント、プロキシ、キャッシュ、およびコンテンツネゴシエーションに対するダウングレードパスを設計できているか。
- 単に登録について議論するだけでなく、インタプリタ、ハードウェア作動、リソース枯渇、プライバシー、および物理的安全性に関するリスクを特定できているか。
最初に確認すべき明確化のための質問
データが独立した感覚メディアを表しているか、複数の相互運用可能な形式がすでに存在しているか、音声や動画と同期する必要があるか、クライアントが未知の機能を安全に無視できるかを確認します。トランスポート、ファイルカプセル化、レイテンシ、キャッシング、デバイス機能の検出、および障害時のUXについて質問します。単一のアプリケーション用のプライベートな形式が1つしか存在しない場合は、トップレベルタイプを作成するのではなく、applicationのサブタイプまたはプライベート登録を選択します。
30秒の回答フレームワーク
まず、既存のトップレベルタイプではセマンティクスを正確に表現できないことを示し、複数の相互運用可能なサブタイプと実際の導入ニーズを検証します。RFC 9694では、明確なスコープとサブタイプの基準、少なくとも1つの記述されたサブタイプ、および完全なセキュリティ上の考慮事項が求められます。妥当性が確認できれば、既存のコンテナでの互換性パスを維持しつつhapticsを提案します。ネゴシエーション、未知のサブタイプの動作、パラメータ登録、およびロールバックを定義します。実装では、デフォルトで危険な機能を拒否し、パースとハードウェアレンダリングを分離し、エネルギー、継続時間、強度のパラメータを制限します。
ステップごとの詳細解説
1. 最初にタイプレベルを決定する
トップレベルタイプはフォーマットを横断したコンテンツのセマンティクスを表現し、サブタイプは具体的なエンコーディングまたは交換フォーマットを識別し、パラメータはネゴシエーション情報を追加します。新しいファイル拡張子ごとにトップレベルタイプを要求してはなりません。コンテンツがaudio、video、image、またはapplicationのセマンティクスに適合するかどうか、および複数の実装間で共有される機能を持っているかどうかを確認します。
2. RFC 9694の基準を検証する
将来のサブタイプの境界が明確であり続けるよう、提案にはそのタイプに何が含まれ、何が明確に含まれないかを明記する必要があります。少なくとも1つの有用なサブタイプが必要です。空のトップレベル名には相互運用性の価値がありません。公開レビュー可能な仕様、エンコーディングと相互運用性の詳細、および各サブタイプまたは重要な共通リスクをカバーするセキュリティ上の考慮事項を含めます。
3. ケーススタディとしてhapticsを使用する
RFC 9695はhapticsを独立した感覚メディアタイプとして定義し、ivs、hjif、hmpgなどのサブタイプを登録しています。触覚データは単独で存在することも、音声や動画と同期することもできます。これをapplicationの下に配置するとメディアセマンティクスが失われます。この事例は、トップレベルタイプがコンテンツクラスを記述し、各サブタイプがエンコーディングの解釈方法を定義することも示しています。
4. ネゴシエーションとフォールバックを設計する
送信者はAcceptとデバイス機能からサブタイプを選択し、サーバーはキャッシュ汚染を防ぐために関連するVaryディメンションを宣言します。古いクライアントが新しいタイプを理解できない場合は、音声または動画コンテナ、静的な代替手段、または明示的な利用不可状態を提供します。未知のサブタイプは実行可能コードではありません。パーサーはサポートされていないパラメータを拒否し、その理由を記録します。
5. パースとハードウェアの境界を設定する
デコード、ポリシーチェック、ハードウェアレンダリングを分離します。リソースの枯渇を防ぐために、ファイルサイズ、継続時間、サンプリングレート、振幅、同時実行ジョブを制限します。触覚データはアクチュエータを制御できるため、ユーザーの同意、デバイスの能力、安全限界の範囲内で動作させる必要があります。サーバーはContent-Typeを信頼境界として扱ってはなりません。
6. 登録と進化を計画する
安定した仕様バージョンと変更管理者を含む、IANAテンプレート、サブタイプの命名規則、パラメータ、およびセキュリティセクションを準備します。新しいパラメータに対する後方互換性のある動作を定義します。未知のパラメータは仕様に従って無視または拒否されます。デプロイを拡大する前に、ネゴシエーションの失敗、フォールバック率、パースエラー、キャッシュヒット、およびデバイスの安全性による拒否を追跡します。
質の高い模範回答
私は「セマンティクス」「エコシステム」「リスク」の3つのテーブルを作成します。データが単一のアプリケーション用のプライベートエンコーディングである場合は、applicationのサブタイプを使用します。複数の相互運用可能な形式があり、ファイル間、ライブストリーム、デバイス間の交換ニーズがある独立した感覚メディアである場合は、RFC 9694を使用してトップレベルタイプを正当化します。提案には、明確な境界、少なくとも1つの有用なサブタイプ、公開仕様、相互運用性の詳細、および共通リスクに対するセキュリティ上の考慮事項が必要です。RFC 9695のhapticsの事例が示すように、トップレベルタイプがメディアセマンティクスを担い、ivs、hjif、hmpgが具体的なエンコーディングを定義します。サーバーはサブタイプをネゴシエートし、古いクライアントには互換性のあるコンテナまたは明示的なフォールバックを提供し、実際のネゴシエーションディメンションに基づいてキャッシュをバリエーション化します。パース、ポリシーチェック、ハードウェアレンダリングは分離され、サイズ、継続時間、強度、同時実行数は制限され、デバイスの機能とユーザーの同意が必要となります。未知のサブタイプや危険なパラメータはデフォルトで拒否されます。Content-Typeは信頼境界ではありません。ローンチ後は、エコシステムを拡大する前に、ネゴシエーション失敗、フォールバック、パースエラー、安全拒否を追跡します。
よくある間違い
- 新しいファイル形式ごとにトップレベルメディアタイプを作成してしまう。
- スコープ、サブタイプ規則、または公開仕様なしでIANA名のみを記述する。
- トップレベルタイプをエンコーディング形式として扱い、パラメータと相互運用性の責任を混同する。
- 未知のクライアントがデータを実行可能コンテンツとして扱うことを許可したり、プロキシやキャッシュの違いを無視したりする。
- Content-Typeのみを検証し、パースリソース、ハードウェア機能、ユーザーの同意を制限しないままにする。
追加の質問と回答
applicationサブタイプの方が適しているのはどのような場合ですか？
構造がアプリケーション固有であり、独立したメディアセマンティクスを持たず、1つまたは少数の厳格に制御されたエンコーディングしか持たない場合に使用します。ベンダー横断的なフォーマット、独立したネゴシエーション、および安定した共有機能が現れた際に、トップレベルタイプを再検討します。
古いクライアントを壊さないようにするにはどうすればよいですか？
送信者が互換性のあるコンテナまたは代替表現を提供し、Acceptおよびデバイス機能からネゴシエートするようにします。古いクライアントは、明示的な利用不可状態、またはレンダリング可能な表現を受け取ります。キャッシュキーには実際のネゴシエーションディメンションを含めます。
触覚データのセキュリティ境界は何ですか？
パーサーはサイズ、継続時間、周波数、強度を制限し、レンダラーはデバイスの安全限界にクリッピングします。ユーザーの同意と機能チェックを必須とします。認証、認可、コンテンツ検証はメディアタイプから独立したままであり、hapticsの値があるからといってペイロードが信頼できるわけではありません。