要約

  • RFC 3382 は、異なる型を持つ名前付きメンバーを一つの値として運ぶ任意の IPP collection 構文を加え、入れ子の collection と将来の任意メンバーも扱えるようにした。
  • メンバー順には規範的な意味がなかった。Printer は別の順序で返してよく、意味を保持するのは位置ではなく、一意な名前と collection の境界だった。

Client が三つのメンバーを送る。Printer が返した三つは同じでも、先頭だったものが末尾に移っている。位置を身元として読む実装には破損に見える。RFC 3382 に従う実装は、名前、構文、値、そしてそれらを囲む collection を照合する。表現が移動しても、所属関係は失われていない。

2002 年 9 月に Standards Track で公開された RFC 3382 は、Internet Printing Protocol の構造上の空白を埋めた。IPP は単純値や反復値を多く表現できたが、型の違う複数属性を一つの単位としてまとめる一般的な方法を欠いていた。PostScript dictionary や Java Map との比較は、名前による対応付けを示すもので、プログラミング言語のオブジェクト全体を持ち込む話ではない。

collection は一つ以上の member attribute から成る。各メンバーは整数、キーワード、範囲など固有の構文と名前を保つ。メンバー自身が collection、あるいは collection の集合でもよい。外側の器は型の違いを消すのではなく、関連する値の周囲に境界を置いた。

ただし、その境界は並びを約束しない。メンバーは任意の順序で現れ、Printer は要求時と異なる順序で保存し返却できた。二番目が常に高さ、最後が常に色という読み方は成立しない。位置は一回の直列化に属し、身元は作用域内の名前に属する。

実際の collection 属性を定義する文書には、名称、単数か複数か、利用文脈、対応メンバーの通知方法が必要だった。さらに各メンバーについて名称、要求水準、構文、意味、制約、対応値、既定値を定める。RFC 3382 は再利用できる文法を提供したのであって、未来の定義作業を省略したのではない。

一つの定義内ではメンバー名が一意でなければならない。同じ名前が別の collection や広い IPP 名前空間に現れることは許される。境界が作用域を与えるからだ。語彙を再利用しながら、各値の中では曖昧でない検索を可能にする設計だった。

同名メンバーを二つ含む collection 値は不正である。Client は送らず、Printer は返してはならない。受信した Printer は bad request として拒否できる一方、実装によってはいずれか一つだけを使って受理できた。しかし「先勝ち」や「後勝ち」は規定されていない。一意性が壊れた後に、順序から可搬な意味を復元することはできない。

この違いは運用上も重要だ。検証側と実行側が別々の重複値を選べば、検査された値と使われた値がずれる。RFC は特定製品にその挙動があるとは述べず、公開だけで採用も証明できない。それでも、実装上の偶然をプロトコル保証へ昇格させない境界は明確だった。

入れ子は表現力を高めた。collection 全体に一律の長さ上限はないが、各メンバーは自分の構文上限に従う。自由形式の文書になったわけではない。末端は IPP 値のままであり、許される構造は定義文書に記される必要がある。

任意メンバーは進化の余地を作った。古い実装が新しいメンバーを理解しなくてもよいが、非対応という事実は元の文脈に結び付けて示すべきだった。Unsupported Attributes Group では、非対応または衝突したメンバーを collection 内に入れて返せる。上位の平坦なエラーにすれば、どの作用域の名前が失敗したのか分からなくなる。

ワイヤ上では begin-collection、member-name、end-collection が構造を囲んだ。古い IPP parser が内部名を通常の最上位属性と誤認しにくいよう考えられていた。互換性は古い実装に新しい意味を理解させる魔法ではない。知らないことを誤解へ変えにくくする枠組みだった。

media-col と job-sheet-col は説明例である。必須・任意メンバー、対応状況、入れ子の定義方法を示したが、それだけで配備済み属性を標準化したわけではない。具体的な collection には別の定義文書が必要だった。

RFC 3380 は job 属性変更の原子性、RFC 3381 は丁合と観測境界に左右される進捗値を扱った。RFC 3382 の問いは別だった。型付きの複数値を一単位として運びながら、物理的な順番を意味にしないにはどうするか。

拡張は RFC 2910 と RFC 2911 を更新した。IPP/1.0 の基礎は RFC 2565 と RFC 2566、要求と設計は RFC 2567 と RFC 2568 にあり、後に RFC 8010 と RFC 8011 が符号化とモデルを統合した。この年代史は、製品採用や印刷成功の証拠ではない。

所属と順序の分離が今も重要なのは、表示が容易に偽の権威を得るからだ。parser が配列を作り、画面がそのまま描き、いつの間にか三番目へ仕様にない意味が付く。正規化、任意メンバーの挿入、map からの再構築で仮定は崩れる。

Lu Heng の最小初期仕様という視点では、将来の全 collection を先取りせず、再利用可能な器と定義者の責任だけを標準化した節度が見える。現実レイヤーの視点では、符号化順、メンバー身元、対応状況、要求受理、物理動作は別々の事実である。

RFC 3382 は、表現が動いても関係を残せるようにした。collection がメンバーを束ね、一意な名前と明示的な境界が理解可能性を守った。順序は、一つの符号化に偶然現れた性質のままでよかった。

出典