要約

  • RFC 1865 は既存の EDI 環境で通信部分をインターネットメールへ置き換え、専用 SMTP による取引相手システムへの直接配送を「保証された」と表現した。一方で、二者間の取引相手契約を残した。
  • RFC 1767 の MIME 封入は EDI の構文・意味を変えず、安全性も自動では与えなかった。RFC 3335 と RFC 4130 は Message-ID、MIC、署名付き MDN を結び付けたが、処理の成功や取引の有効性を別問題とした。
  • メール受理、配送、暗号学的受領、EDI 処理、業務確認、商業上の決定は別々の記録である。前段の成功を後段の権限に読み替えてはいけない。

受信箱の先に残った仕事

1996 年の買い手が、仕入先から電子注文を受け取る場面を考える。最終メールサーバーはデータを受理し、仕入先側には成功応答が残る。それでも、買い手はまだ注文を引き受けていない。重複かもしれず、EDI 構文に誤りがあるかもしれず、価格や納期が契約条件に合わないかもしれないからだ。

RFC 1865 は、インターネットに不慣れな EDI 利用者へ向けた 1996 年1月の Informational 文書である。提案は、業務プログラムや EDI 変換を捨てることではなかった。両者の間にある通信モジュールをインターネットの仕組みに置き換えることだった。

同文書は、専用 SMTP 接続なら相手システムへ直接届けられ、配送が保証されると述べる。他方、ストア・アンド・フォワード経路の完全性は中継システムに依存するとした。この対比は通信設計として理解できる。ただし「相手システム」を「相手企業の意思」に置き換える根拠はない。

標準化された文書も、まだ業務への入力だった

RFC 1865 は EDI を、標準化されたビジネス情報のアプリケーション間通信と定義した。そして、人間同士の連絡、送金、共有情報資源まで含む電子商取引のほうが広い概念だと区別した。

ここには重要な抑制がある。注文書や請求書が標準形式で届くことと、支払い・履行・同意が起きることは同じではない。EDI は業務手続きへの入力であり、その手続きを代行する権限ではない。

また、取引相手同士の契約は消えなかった。従来の専用メールボックス名をインターネットアドレスに置き換えることはできても、相手の識別、重複時の扱い、応答期限、法的効果は合意で定める必要がある。RFC 1767 も、EDI-consent の利用を明示的な二者合意に限った。

MIME は運べる形を決めた

RFC 1767 は EDI-X12、EDIFACT、EDI-consent の MIME 型を定義した。送信側では業務プログラムから EDI 変換、MIME 処理、メール投入、SMTP へ進み、受信側では MIME を外し、EDI 変換を経て、ようやく業務処理へ渡る。

文書は、元の EDI 構文と意味を変更しないと明記し、それ自体には安全機構がないとも述べた。つまり MIME は、バイト列をメールで壊さず扱うための種類と包み方を提供する。内容が正当か、相手が本物か、改変されていないか、注文として受け入れられたかは別途検証する。

共通封筒が相互接続を可能にしたとき、封筒が中身の判定まで済ませたように見えやすい。RFC 1767 の処理順序は、その錯覚を退ける。置き換わったのは中間の伝送部品だけだった。

署名付きの失敗通知という進歩

RFC 3335 は、署名と暗号化を使う安全なインターネット EDI を整理した。MDN には元の Message-ID、受け取った内容から計算した MIC、受信側の署名を含められる。送信側は元メッセージとの対応、内容指紋、応答者の署名を検証できる。

これは SMTP 応答より強い証拠である。ただし強い証拠と広い権限は同じではない。RFC 3335 は、送信者が署名付き受領を検証した後に「受領の否認防止」という法的事象を位置付けた。適用法、証明書方針、署名者の権限まで自動決定したわけではない。

RFC 4130 の AS2 は、処理に失敗した場合でも、署名付き受領が要求されていれば返すよう求めた。失敗内容は disposition に入る。これは欠点ではない。沈黙では、通信断、停止、復号失敗、構文拒否、方針拒否を区別できない。署名された否定的応答なら、どの段階に到達し、どこで止まったかを残せる。

反対に、合意上必要な署名付き受領が返らない場合、取引の有効性は相手同士で解決すべきだと RFC 4130 は述べる。技術は証拠を支えるが、受領の否認防止そのものを定義しない。そこは業務・法務の要件だからである。

画面表示さえ理解の証明ではない

RFC 3798 は一般の MDN について、受信者が要求を無視できること、displayed でも内容を読んだ、理解したとは保証できないことを明記した。

この注意は機械間通信にも通じる。SMTP 応答を配送完了、MDN を業務処理、署名を契約権限、表示を理解へと膨らませれば、途中にいる主体が消えてしまう。

残すべき受領は少なくとも、送信した正確な EDI オブジェクト、メール系による受理・配送、対応付けられた MDN と MIC、EDI 変換・処理結果、業務アプリケーションの機能確認、権限ある商業プロセスの決定である。実装ごとに名称や文書数は異なっても、この権限分離は変わらない。

オープンな運搬と二者間統治

RFC 1865 は、分散ディレクトリ、協調的な経路制御とアドレス解決、複数 ISP やメールサーバーによる冗長化を挙げた。専用の付加価値通信網を唯一の仲介者にしなくても EDI を運べる構想だった。

しかし運搬が分散しても、取引関係は無許可型にならない。どのアドレスを相手と認め、どの証明書を使い、いつ再送し、どの応答で在庫や債務を動かすかは、依然として相手同士が負う。

インターネットが成し遂げたのは、一つの世界的仲介者になることではない。交換可能な通信部品と、検証できる証拠材料を提供したことだった。

仕様から言える範囲

公式文書は、RFC 1865 が EDI のインターネットメール移行を説明したこと、RFC 1767 が意味を変えずに MIME で包んだこと、RFC 3335 と RFC 4130 が署名・相関・MIC の証拠を強めたこと、RFC 3798 が表示と理解を区別したことを示す。RFC 5321 の責任移転もメール配送の範囲である。

一方、特定企業での導入、注文の成立、支払い、裁判所の判断、全実装の正しさは示さない。だからこそ歴史的結論は明確になる。インターネット EDI の信頼は万能な一枚の受領ではなく、発行者と効力の違う受領を順に保存できることから生まれた。

出典