[2] ni: は、対象となる情報のハッシュ値を使って識別する URL scheme です。

[4] 「ni」は Named Information を表します >>3。

仕様書

構文

[6] ni: URL は、 URL scheme の後に、 //、 authority、 /、 ダイジェストアルゴリズム、 ;、 ダイジェスト値、 ?、 query が続きます。ただし authority と ? 以下は省略可能です。 >>3

  1. ni://
  2. ?
    1. authority
  3. /
  4. ダイジェストアルゴリズム
  5. ;
  6. ダイジェスト値
  7. ?
    1. ?
    2. 名前=値
    3. *
      1. &
      2. 名前=値

[14] ダイジェストアルゴリズムとダイジェスト値は、 どちらもそれぞれ1文字以上の RFC 3986 unreserved でなければなりません >>3。構文上パーセント符号化が認められていません。

[10] ダイジェストアルゴリズムとダイジェスト値は、 この URL によって表されるオブジェクトについての値です。 ダイジェストアルゴリズムは、 IANA に登録された名前を使って表します >>3。

[28] バイナリ表現 (>>27) ではダイジェストアルゴリズムを Suite ID というアルゴリズムに割り当てられた数値で表します。 nih: では、文字列の名前と数値のどちらも認められています。 しかし ni: では文字列しか認められていないようです。

[11] ダイジェスト値は、 RFC 4648 base64url で符号化したもの (詰め文字 = なし) でなければなりません >>3。

authority

[7] authority は、URL によって表されるオブジェクトにアクセスするのを補助するものです >>3。

[18] http: などの多くの URL scheme とは違って、 authority は ni: URL においては重要なものとはされていません。 authority の値に関わらず、 ダイジェストの部分で URL によって識別されるものは決まります (ハッシュ値URLの比較を参照)。

[8] authority は省略可能です >>3。その場合 ni:/// から始まる URL となります。 (// は省略できません。)

[9] authority は RFC 3986 の構文が参照されています >>3 が、 それ以上の制約や意味や処理モデルは定義されていません。

query

[12] query は RFC 2616 の http: URL のものと同様とされています >>3。名前=値&名前=値のような構文を指している >>3 とありますが、 RFC 2616 にはそのような規定がなく (実際にはそのような構文は HTTP ではなく、 HTML で用いられている application/x-www-form-urlencoded のものです。)、 何が認められているのか曖昧となっています。

[15] query ではパーセント符号化が認められています。特に非ASCII文字は、 UTF-8 でパーセント符号化しなければなりません >>3。

[20] query は & 区切りの名前と値の組の列として定義されていますが、 そのそれぞれのことを引数parameterやクエリー文字列属性query string attributeと呼ぶ >>3 ようです。

[19] query の解釈の詳細についてはまったく言及もありません。 引数の順序が重要なのか、未知の引数をどう扱うのか、 引数の名前の大文字と小文字を区別するのか、 同じ名前の引数を複数指定できるのかなどは不明です。

[21] 引数は、 IANA に登録することになっています >>3, >>30。 現在次の引数が存在しています。

相対 URL

[16] 相対URLとして用いられることも想定されているようです。 RFC には次のような例があります。

        <base href="ni://example.com">
...
        <p>Please check <a href="sha-256;f4OxZX...">this document</a>.
[17] ところでこの base href は >>6 の構文に適合していません。

比較

[5] ハッシュ値URLの比較を参照してください。

処理

[13] 実装は、 URL の送信、受信、処理に当たって URL と資源の対応関係の整合性integrityを検査して構わない >>3 とされています。ここでいう整合性が具体的に何を指しているのかはよくわかりません。

HTTP URL への変換

[22] ni://n-authority/alg;val?query-string のような ni: URL は、 http://h-authority/.well-known/ni/alg/val?query-string のような http: URL (や https: URL) に変形できます >>3。

[25] ここで h-authority は、 n-authority が空でなければ、 同じ値でなければなりません。空の時は、応用の文脈により適当な値を設定できます。 >>3

[26] 例えば Webページ内なら、その起源と同じものとできます >>3。

[23] この変形は ni: に対応したクライアントが使えない時にはいつでも利用できます >>3。しかし得られるデータが意図したものとは限りません >>3。また、 HTTP から ni: への逆の変形もできますが、 やはり意図したものになるとは限りません >>3。

[24] 応答は 3xx かもしれませんが、 HTTP に従い正しく処理できなければなりません >>3。

応用

[33] 使っているところを見たことがないです。

[34] 聞いたことある?

バイナリ形式

[27] RFC は、可変長のバイナリ形式も規定しています >>3。

人間可読形式

[29] 姉妹 URL scheme として、人間可読と称する nih: URL scheme が定義されています。

歴史

[1] Subresource Integrity ( ( 版)) http://www.w3.org/TR/2014/WD-SRI-20140318/

[31] [Integrity] Revisit RFC6920 URIs for benefit of servers and Semantic Web applications (Austin William Wright 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0048.html

[32] hash-uri/README.md at master · hash-uri/hash-uri ( ()) https://github.com/hash-uri/hash-uri/blob/master/README.md

Uses uncommon URI syntax that could break many parsers (; path arguments). The "ni" (Named Info) term is less meaningful and overlaps with URNs (Uniform Resource Names), which could potentially lead to use for non-content addresses.

[35] SRI が逃げたのはやはり正しかった。 URL にすることの意味がなく、 逆にパーセント符号化とか要らぬ複雑性を持ち込むだけだからな。

[36] 参照元にハッシュ値を埋め込む提案と失敗の歴史の1頁でした。