処理モデル
[4] 実装は、 ct 引数の構文解析に対応しなければなりません
>>1。
[10] 利用者エージェントがMIME型 sensitive であり、
ni: URL に ct
引数が指定されており、
MIME型を指定するプロトコルによってオブジェクトを取得した場合には、
両者のMIME型が一致するなら、問題ありません。
一致しない場合には、セキュリティーエラーの疑いがあるものとして扱うべきです。
>>1
[11] MIME型の一致の判定は、 RFC 2045 5.1節によります >>1。
[12] この RFC 2045 の5.1節の参照が十分ではない気がします。
RFC 2045 は比較方法を明確には定めていません。大文字と小文字を区別しないことや、
引数値の引用符が値の一部ではないことは明記されていますが、
比較において引数の有無が影響するのかや、
引数固有の値の正規化が影響するのか (例えば charset
引数では大文字と小文字を区別しないなど。)、
引数の順序や空白の違いなどが影響するのかといった詳細は、
規定されていません。[6] ni: URL を使うプロトコルは、
その処理の対象となる MIME型について名前とデータの整合性をどう検証するかを規定する必要があります。また、
CTE その他 MIME の性質を考慮する必要もあるでしょう。 >>1
[7] 実装は、最低でも application/octet-stream
と CTE 明記なし (binary と同じ) の場合について名前とデータの整合性の検証に対応するべきです >>1。
[14] このあたりの規定の意味するところはいまいちよくわかりません。
RFC では明確な処理モデルが定義されていません。
MIME型や、 CTE その他の MIME の性質によってハッシュ値の算出方法が変わるということなのでしょうか
(>>3 も参照)。
(text/* なら改行を正規化するとか??)
最低でも application/octet-stream は対応するべきと言っていますが、
その方法は述べていません。バイナリデータとしてそのままダイジェストアルゴリズムの入力に使うということなのでしょうか。
プロトコルに規定を委ねているので、構文を定義するだけで、実際の利用方法を定義する気はないのかもしれません (そんなものに意味があるのかわかりませんが...)。[8] なお、ハッシュは CTE の除去後の生データで計算します >>1。
[9] だとすると >>6 や >>7 の CTE についての言及は意味がわからないのですが...
すべて CTE の除去後の話なら、 CTE によって動作を変えたり、
わざわざ定義したりする必要はないはずです。