[2] ni: URL の
ct 引数は、
その URL で識別される資源のMIME型を表します。
[3] ct 引数は、関連付けられているデータの
MIME型を指定するものです >>1。認証されている情報源から外部の情報源への安全な参照のためにダイジェストを使う場合、
そのダイジェストの意味はMIME型など関連付けられているメタデータの関数となることがあるため、
ni: URL にはMIME型を指定できます >>1。
[13] MIME型の定義として RFC 6838 が参照されています >>1 が、これが構文の定義として参照しているのかは不明瞭です。比較については RFC 2045 を参照していて (>>11)、両者の構文の定義は厳密には一致していません。
[4] 実装は、 ct 引数の構文解析に対応しなければなりません
>>1。
[10] 利用者エージェントがMIME型 sensitive であり、
ni: URL に ct
引数が指定されており、
MIME型を指定するプロトコルによってオブジェクトを取得した場合には、
両者のMIME型が一致するなら、問題ありません。
一致しない場合には、セキュリティーエラーの疑いがあるものとして扱うべきです。
>>1
[11] MIME型の一致の判定は、 RFC 2045 5.1節によります >>1。
[6] ni: URL を使うプロトコルは、
その処理の対象となる MIME型について名前とデータの整合性をどう検証するかを規定する必要があります。また、
CTE その他 MIME の性質を考慮する必要もあるでしょう。 >>1
[7] 実装は、最低でも application/octet-stream
と CTE 明記なし (binary と同じ) の場合について名前とデータの整合性の検証に対応するべきです >>1。
text/* なら改行を正規化するとか??)
最低でも application/octet-stream は対応するべきと言っていますが、
その方法は述べていません。バイナリデータとしてそのままダイジェストアルゴリズムの入力に使うということなのでしょうか。
プロトコルに規定を委ねているので、構文を定義するだけで、実際の利用方法を定義する気はないのかもしれません (そんなものに意味があるのかわかりませんが...)。ni:///sha-256-32;f4OxZQ?ct=text/plain
charset引数では大文字と小文字を区別しないなど。)、 引数の順序や空白の違いなどが影響するのかといった詳細は、 規定されていません。