要約

  • RFC 3940 の object_transport_id は、送信者ごとに配送中の NormObject と修復を結び付ける番号であり、世界で永続するコンテンツ識別子ではなかった。
  • 16ビットの番号は長いセッションで一周し、再び使われる。配送後まで残す名前は、アプリケーションが NORM_INFO または内容本体に定義し、保存する必要があった。

返事を減らすほど、何を直すかが重要になった

一つの大きなデータを何千もの相手に同時配信するとき、全受信者が全パケットへ確認を返せば、信頼性のための通信が本体を圧迫する。NORM は成功時の沈黙を利用した。欠落を見つけた受信者だけが否定確認を送り、前方誤り訂正の断片を使って複数の異なる欠落を効率よく埋める。

ただし、修復する断片がどの送信物に属するかは明確でなければならない。2004年11月に実験的仕様として出た RFC 3940 は、送信者が増加順に割り当てる object_transport_id を用意した。同じオブジェクトの初回送信と修復要求は同じ値を使う。プロトコルが運ぶ送信者識別子と組み合わせれば、受信者は現在のセッションで動いている NormObject を区別できた。

これは「この断片はどの配送作業に属するか」への答えである。「配送後の台帳で何という資料なのか」への答えではない。

FILEという名前にも永続性はなかった

NORM は、メモリー上の静的データ、ファイル、終わりの決まらないストリームという三つのオブジェクト型を扱った。ところが NORM_OBJECT_DATA と NORM_OBJECT_FILE の差は、受信側がメモリーと不揮発性ストレージのどちらを用意するかというヒントにすぎない。それ以外では、どちらも有限の内容単位として同じように運ばれる。アプリケーションの判断で、静的な内容をストリームに載せることさえできた。

したがって FILE は、ファイル名、パス、版、所有者を意味しない。ある地図の全バイトを正しく復元しても、それが最新版か、撤回済みか、別の地域の同形式データかは分からない。保管場所のヒントと、内容の意味を取り違えると、輸送上の成功が業務上の正しさに見えてしまう。

16ビットの輪は閉じる

オブジェクト番号は16ビットで、各送信者が独立に管理した。ある数字だけを抜き出しても、送信者、送信者のインスタンス、セッションの状態、カウンターが何周目かがなければ対象を決められない。RFC 3940 は、非常に長い、あるいは期限のないセッションでは値が再登場し得ると書き、現在の状態から大きく外れた番号を受けた受信者に再同期を求めた。

仕様はさらに重要な否定を置いた。NORM のメッセージヘッダーは、データ内容のグローバル識別やアプリケーションレベルの識別を提供しない。輸送識別子が有効なのは、送信者がそのオブジェクトを送信または修復している間だけである。数字が単調に増えることは、有限の範囲で順番が分かるという意味でしかない。

2009年11月、RFC 5740 が RFC 3940 を廃止し、NORM を標準化過程へ移した。だが境界は消えなかった。後継文書は、長いセッションでは番号が一周して繰り返されると、さらに断定的に記した。実験から標準へ進んだのは配送方式であり、短い番号が永続IDへ昇格したのではない。

横に添える小さなカード

内容の意味を運ぶ余地はあった。NORM_INFO は、一つのオブジェクトにアプリケーション定義の帯域外コンテキストを添える。MIMEタイプが例として挙げられ、受信者はその情報を見て信頼配送へ参加するか判断できた。INFOを取り逃がした場合は、その小さな単位自体を修復要求できる。

しかしINFOは登録簿ではない。利用は任意で、意味はアプリケーションが決め、全体が送信者の一つのペイロードに収まらなければならない。原子的であるため素早く修復できる一方、容量は限られる。永続ID、ダイジェスト、版、署名、ファイル名のどれも必須ではない。アプリケーションはINFOに独自の識別子を入れてもよいし、内容本体へ埋め込んでもよい。ただし規則と保管責任は自分で持つ。

INFOがデータと同じ輸送番号を共有することで、配送中は正しい説明カードを正しい荷物へ結び付けられる。修復期間の終了後、その番号だけを保存して送信者インスタンスやセッション世代を捨てれば、後日の番号再利用を見分けられない。プロトコルが二つの内容を同一視したのではなく、保管側が番号の有効範囲を失ったのである。

正しく直したデータを、間違った棚へ置く

受信キャッシュがプロトコルの送信者識別子と16ビット番号だけを永続キーにしていたとする。一度切断し、世代状態を失い、カウンターが一周した後に戻る。新しいオブジェクトは現在の送信として正しく復元される。それでもキャッシュは見覚えのあるキーを見て、古い題名、古い有効期限、古いアクセス権を新しいバイトへ貼り付けるかもしれない。配送の完全さが、誤った関連付けを完全にしてしまう。

これは仕様から導くリスク例であり、実際の事故を主張するものではない。重要なのは証拠の役割を混ぜないことだ。輸送状態は、断片がどの進行中オブジェクトに属したかを示せる。アプリケーションが用意したダイジェストは、バイトの一致を比べられる。永続識別子は、配送を版管理された記録へ接続する。公開可否や権限には、さらに別の判断記録が必要になる。

RFC 3940 の歴史的な価値は、必要以上の権威を番号に与えなかった点にある。多数への修復を調整する最小限の識別を作り、そこで止まった。プロトコルは運び、アプリケーションは覚える。輸送より長く生きる意味には、輸送とは別の名前が要る。