要約

  • RFC 3072のSDXFでは、各チャンクが識別子、フラグ、3バイトの長さ、内容を持つ。読取例は未知の識別子を無視し、次のチャンクへ進む。
  • それで保たれるのは走査の継続であって意味の理解ではない。アプリケーションには共有された意味、変換表、処理実装、値を使う権限が別途必要だ。

2001年3月、Max WildgrubeはRFC 3072で、階層データをプラットフォーム間で交換するStructured Data Exchange Format（SDXF）を説明した。その「自己記述型」という性質は、読み手がどこまで分かるという主張なのかを分けて読む必要がある。文書は個々の要素の意味を知らなくてもデータを展開できると述べる。一方、読取例では既知のチャンクIDだけをswitchで処理し、既定の分岐を置かず、次のチャンクへ進む関数を呼ぶ。未知の項目は解釈されずに残るが、解析は続く。

その仕組みはチャンクの形にある。通常のチャンクは、ゼロ以外の2バイトID、1バイトのフラグ、3バイトの内容長、その後の内容から成る。構造化チャンクはさらにチャンクを含み、階層を作れる。現在の形式規則に従って次の境界を見つけられれば、内容を解釈しなくても先へ進める。パーサーが把握したのは終端位置であって、そのIDが特定の業務やプロトコルで持つ意味ではない。

RFC 3072は、SDXFを使うアプリケーションプロトコルの拡張ルールとして、未知のチャンクIDを無視し、チャンクの順序に依存しないことを提案した。旧版の読取側が新しい拡張を許容する助けにはなる。しかし、送信側の取引でその項目が任意なのか、アプリケーションの解釈を変えるのか、捨てると重大な処理が変わるのかは決めない。走査を継続できることは、適用範囲のある互換性動作であり、項目が常に無関係だという宣言ではない。

形式自体が、境界の先にある別の合意も示している。RFC 3072は数値をビッグエンディアンにそろえ、ISO 8859-1を内部表現として提案し、変換表の設定を認める一方、UTF-8のデータ型も定義した。圧縮と暗号化はフラグ、方式番号、実装関数に依存する。両方を使う場合は圧縮が先で、暗号化には鍵が要る。チャンクの境界を読めても、文字変換、方式実装、鍵、IDに対応するアプリケーション側の定義がなければ、内容の利用可能性は別問題だ。

現在のIANA SDXF登録簿には、圧縮方式RUN-LENGTHとDEFLATE、暗号方式01のAESが記録されている。登録は方式番号を示すだけで、受信側に実装があるか、特定の内容が正しく処理されたかは証明しない。RFC 3072はInformationalであり、Internet Standardではない。ここで参照した記録から、実装普及や採用を断定することもできない。

大切なのは証拠の層を混ぜないことだ。長さは形式に従ったバイト境界を示す。識別子はアプリケーション定義への参照にすぎない。変換表は文字を写し、方式番号は処理を選ぶが、実装と鍵がなければ実行できない。抽出値を使う権限はさらに別の規則で決まる。後年のRunning-Code Primacyは各層の実際の動作を観察する視点であり、Reality Layersは象徴的な意味付けと実行可能な効果を分ける視点だ。いずれもWildgrubeの主張としてではなく、後から適用する分析枠として用いる。

ライブラリーの戻り値も、この区別を実行時に示す。反復処理は次のチャンクへ到達したと報告できても、内容の抽出はバッファー不足、変換不能、方式の未実装、鍵の欠落などで失敗し得る。それぞれは別の制御点についての証拠であり、一つの「メッセージ解析成功」という判定に畳み込めない。そうすれば、未知の項目があっても構造上の走査は続く一方、意味と実行条件は未確定のままだという SDXF の境界を消してしまう。アプリケーションは、自らのスキーマと判断規則が結論を出すまで、その不確実性を保持する必要がある。

出典