[2] nih: は、対象となる情報のハッシュ値を使って識別する URL scheme です。 ni: URL よりも「人間可読」>>3 とされています。

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

仕様書

可読性

[6] ni: は base64url を使うため、 大文字と小文字が混在するなど口頭伝達に不向きです。 対して nih: は限られた英数字の小文字しか使いませんし、 checkdigit も入っているので、より伝達しやすいように設計されています。

[7] ... とか説明されていて、いまどきハッシュ値の口頭伝達ってどんな冗談かと思いますが、 RFC 6920 の発行は4月1日ではありませんし (4月ではあります。)、 実際に真剣に検討されたようです。。。 どんな目的に使おうとしてたんでしょうかね。

構文

[8] nih: URL は、 nih:、 ダイジェストアルゴリズム、;、 ダイジェスト値、;、 checkdigit で構成されます。ただし最後の ; と checkdigit は省略できます。 >>3

  1. nih:
  2. ダイジェストアルゴリズム
  3. ;
  4. ダイジェスト値
  5. ?
    1. ;
    2. checkdigit

[10] ダイジェストアルゴリズムは、 ni: と同じ >>3 で IANA に登録された短い文字列です。 アルゴリズムに割り当てられた Suite ID を使うこともできます >>3。 実装は、対応しているアルゴリズムについて Suite ID も対応しなければなりません >>3。

[15] Suite ID に先導0が認められているのかは不明です。

[11] ダイジェスト値は、1文字以上の小文字の十六進数による base16 で符号化したものです >>3。ただし読みやすいように任意の位置に - を任意の個数挿入できます >>3。

[12] ダイジェスト値がバイト列なら十六進数は偶数個ないといけないはずですが、 そのような構文の制限は明記されていません。

[13] checkdigit は、 ISO/IEC 7812 Luhn's mod N algorithm (N は 16) により計算したものでなければなりません。 その入力は符号化したダイジェスト値ですが、 - はすべて除去し、十六進数をそれぞれ 0-15 の範囲の値として解釈したものとします。 >>3

[9] ni: と違って authority や query は使えません。相対URLも使えません。

比較

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

処理

[14] なぜか処理モデルは明記されていません。 checkdigit が指定できるということは、それが不整合な場合、エラーとして扱うのが適切なように思われますが、 そう明記はされていません。

応用

[17] 使われているところを見たことがありません。

[18] 噂にすら聞いたことがないw

関連

[1] NIH ではありません。

歴史

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

メモ