要約

  • RFC 1197 の ODA は、複数書体、raster image、geometric graphics を扱う抽象的な文書 architecture だった。実用的な交換には、共通 entity を選ぶ DAP と、各製品の native object への mapping が別途必要だった。
  • NSF の EXPRES project は NIST DAP と Andrew、Diamond、Interleaf の機能を材料に研究提案の電子送付を調べた。短い RFC は、忠実度や普及率の測定結果を報告していない。
  • MIME/X.400 の後続仕様は ODA body の byte、profile、class を別々に扱った。同じ byte が届くことと、同じ文書として解釈・表示・編集できることは同一ではなかった。

後年の “None” から境界が見える

RFC 2161 は1998年、ODA を MIME と X.400 で運ぶ定義を独立した文書にまとめた。Category は Experimental であり、Internet Standard ではないと明記している。

その対応表は ODA data の conversion を “None” とした。しかし同じ文書は profile と class を維持し、Q112 の object identifier と formatted、processable、formatted-processable の対応を定めた。値が欠ければ default も使う。

つまり “None” が閉じるのは data body を別形式へ書き換えるかという問いだけだ。どの application subset を名乗るか、どの class か、受信 software がそれをどう native object にするかは残っている。変換しない byte と、解釈しなくてよい document は別物である。

この切り分けを遡ると、RFC 1197 の短い経験報告に行き着く。

ODA は paragraph より抽象的な場所にいた

Mark Sherman が1990年12月に出した RFC 1197 は、ISO 8613 Office Document Architecture を multimedia mail と file exchange に使った経験を紹介する。RFC Editor の記録と IETF Datatracker の記録は、この文書を Informational として保存している。標準を制定する RFC ではない。

ODA は複数書体の text、raster image、geometric graphics を表現でき、X.400 のような関連標準でも使われていた。対象は単純な文字列ではなく、複合文書だった。

一方で RFC は ODA を “very abstract” と呼ぶ。定義するのは composite logical object class のような entity であり、application が日常的に扱う paragraph のような entity ではない、と対比した。

ここから「ODA は段落を一切表現できなかった」と結論してはいけない。正確な境界は、一般 architecture が交換共同体のために paragraph という共通 object とその挙動を選び終えてはいなかった、ということだ。

抽象性には理由がある。一製品の内部 model を全員に強制せず、異なる文書 system を包める。しかし中心が中立であるほど、edge には明示的な合意が必要になる。

DAP は可能性を互換契約へ縮めた

RFC 1197 が必要だとしたものが document application profile、DAP である。DAP は ODA の中で共通に使う entity を定める。その後、各 system は DAP entity と自分の entity の間に mapping を作る。

profile owner と product implementer の判断は違う。前者は community が持ち運べる subset を選ぶ。後者は、その subset を local paragraph、style、page、graphic object などへどう結び付けるか決める。

したがって “ODA support” は十分な capability record ではない。同じ ODA family を読めても DAP が異なるかもしれない。同じ DAP を掲げても optional property や extension の実装が異なるかもしれない。必要なのは profile、version、class、extension、送受信両側の map である。

小さい profile は standards の敗北ではない。大きな option space のうち、独立実装が試験できる範囲だけを shared promise にする仕組みだ。製品固有の豊かな機能は残せるが、portable だと証明なしに呼ぶことはできない。

EXPRES は三つの製品表面を一つに見せなかった

National Science Foundation が資金を出した EXPRES project は、研究提案を ODA で表し、電子 mail で NSF に提出する用途を調べた。Carnegie Mellon University と University of Michigan の group が、McDonnell-Douglas Aerospace Information Systems、NIST、Interleaf と協力した。

RFC によれば、strategy は NIST DAP と Andrew、Diamond、Interleaf が提供する機能を基礎にした。三つの application が最初から同じだったのではない。共通 profile を各々の機能へ結ぶこと自体が研究面だった。

ただし RFC は二ページしかない。conversion success rate、layout 差分、round trip、performance、特定 proposal の受理を報告していない。詳細は別の1991年の書籍に置かれ、この source set には含まれない。

参加名は provenance であって、結果の保証ではない。書籍の内容は著者の見解であり、各参加組織の policy ではないという disclaimer もある。

MIME は format 名の隣に profile を置いた

1992年の RFC 1341 は、初期 MIME に application/oda subtype を置いた。body が ODA standards に従う ODIF representation であることを示す。同時に Content-Type は DAP を示す profile parameter を持つべきで、例は profile=Q112 だった。

二つの identifier は異なる問いに答える。subtype は representation family、profile はその中で使う application contract である。type だけで意味が完結するなら profile は要らない。

header は受信 agent が handler を選ぶ材料になる。しかし Q112 implementation の正しさ、未知 entity の不在、同じ layout、編集構造の保持を証明しない。RFC 1341 は現在 obsolete であり、ここでは当時の境界を示す史料としてだけ使う。

Byte copy の外側に二つの mapping があった

1993年の RFC 1494 は、1988 X.400 body と MIME body の equivalence を定めた。ODA body の conversion type は “Byte copy” で、data はそのまま運べた。

それでも X.400 の document-application-profile object identifier は MIME profile へ、document-architecture-class は MIME class へ別に mapping された。body、profile、class は一つの record ではなかった。

MIME 側から値が欠けると、Q112 と formatted-processable が default になった。gateway は ODA object 内部の document characteristics を調べてもよいが、そこが optional なので必須ではなかった。

default は処理を deterministic にする一方、sender の意思を観測してはいない。後の auditor が declared、extracted、defaulted を区別できなければ、gateway の選択が author の主張に変わってしまう。

Byte copy が証明するのも body の不変性までだ。受信側で同じ native model、同じ rendering、同じ editability が得られたかは後続 evidence を要する。

Extensible body の能力は時間とともに動いた

RFC 2161 の security section は、ODA body が複雑な構造を持ち、各部分の capability を見極めにくいと述べる。ODA は extensible なので、新しい content portion が加われば threat も変わり得る。

同時に、当時 ODA に関係する既知の security risk はないと書く。ここから導けるのは、capability inventory と再評価が必要だということまでであり、過去の exploit を作ることではない。

outer type が同じでも、profile、extension set、parser、local mapping は更新される。互換性も安全性も static badge ではなく、artifact と version に結び付いた観測になる。

受信した文書は最後に見なければならなかった

証拠の順序は、ODIF byte、media type、profile の出所、class、gateway action、receiver capability、local map、rendered output、保持された structure、editability、round trip、institutional outcome となる。

hash は byte identity を示す。profile は期待 subset を狭める。adapter version は適用 rule を示す。visual/structural comparison は初めて output の差を示す。それぞれ必要だが、互いの権限を借りられない。

RFC 1197 の paragraph は、抽象標準への非難ではない。共通中心が薄いほど、異なる system が参加しやすい。その代わり profile が共通言語を選び、edge が翻訳責任を負い、receiver が実際に必要な document かどうかを判断する。

情報源と限界

これらは現在の普及、market share、製品品質、EXPRES の定量的忠実度、既知 incident、特定 proposal の成功を証明しない。