要約

  • RFC 1911 は、DTMF とアナログ再生に頼る機器間転送を、MIME と ESMTP の限定プロファイルへ移そうとした。
  • 同じ機械が転送と最終配送を担っても、SMTP 受理、ヘッダー保存、音声復号、正しい受信箱への格納、利用者の聴取は同じ事実ではない。
  • 1996 年と 1997 年の実演を踏まえた RFC 2421 は初版を大幅に変更し、実装試験が仕様を修正する証拠になった。

一体化は証拠を一体化しなかった

当時の音声メール装置は、電話交換機につながる専用コンピューターだった。呼を受け、録音し、利用者は電話機の数字キーで受信箱を操作する。遠隔機への従来の転送では、DTMF で相手を選び、音声をアナログで再生する方式が使われた。

RFC 1911 は 1996 年 2 月に Experimental として公開され、Internet Standard ではなかった。公開された最小共通プロファイルの試みであり、音声装置が汎用メールとして成熟したことを認証する文書ではない。

RFC 1911 は MIME と ESMTP を利用してデジタル化した。既存のメール基盤を使えることは大きい。しかし装置が汎用メールサーバーに変身したわけではない。テキストを表示できない場合があり、転送エージェントとユーザーエージェントを一体化し、最終配送はするが中継はしないことが多かった。受信者一覧、Received、Message-ID を完全に保存できないストアも想定された。

経路が一台で終わるから簡単なのではない。むしろ、その一台が意味を捨てた後に別の記録から復元できない。宛先一覧を失えば全員返信はできない。追跡行を失えば配送経路の検証が弱くなる。識別子を失えば通知との照合が難しい。ワイヤ上の適合と保存後の意味は別だった。

最小プロファイルは能力の上限ではない

初版が求めたのは共通の下限である。追加のメディアや機能は許されたが、送信先が対応すると明示的に分かる場合に限って送るべきだった。送信先能力のディレクトリも想定されたが、作り方や更新責任はローカル事項とされた。

したがって、ディレクトリの一行は現在の実行状態を証明しない。古いかもしれず、別装置を指すかもしれず、インストール済みだが無効な機能を表すかもしれない。設定上の判断と、その SMTP セッションで得た EHLO 応答は別に保存する必要がある。

汎用メールゲートウェイがプロファイルを実装することも可能だった。ただし推奨 ESMTP 拡張がなければ性能低下があり得る。名称上の対応と、実際の転送条件、内容、保存、再生は分けて評価しなければならない。

数字の受信箱からドメインへ

電話利用者が入力するのは短い数字列でも、Internet メールにはローカル部とドメインが必要だった。どの FQDN に変換するかは装置側の実装に任された。

同じ内線番号は複数組織に存在できる。番号計画も変更される。DNS が選択済みドメインを正しく解決しても、数字からそのドメインを選んだ判断までは証明しない。入力値、変換規則、DNS 観測、接続先、最終受信箱を一続きにしなければならない。

診断用の postmaster は必須だった。初版の loopback は新しいメッセージを postmaster から送り返したが、RFC 2421 はセキュリティ上の懸念から非推奨にした。試験用途の便利さが、恒久的な安全性を保証しなかった例である。

音声の時間と転送の大きさ

利用者は分で考える。ESMTP の SIZE は MIME 包装を含むバイトを数える。音声コーデックが違えば同じ時間でも大きさが変わり、バイナリ転送が使えず Base64 にすればさらに増える。

共通の必須形式は Audio/32KADPCM だった。他の標準形式や独自形式は、送信先についての明示的知識なしには相互運用性を下げる。共通コーデックは最低限の選択肢を保証するだけで、個別装置の音質、復号成功、聞き取りやすさを保証しない。

SMTP サーバーが 8 ビット、バイナリ、分割転送や SIZE を広告しても、それは特定ホップの受入宣言である。最終ストアがヘッダーを残すこと、再生装置が形式を扱うこと、利用者が聞くことまでは含まれない。

エラーは機械から電話へ渡る必要があった

人間の運用者がいない装置では、文章だけのバウンスは役に立たない。構造化された配送状態を装置が解析し、電話利用者に意味のある案内へ変換する必要があった。

それでも通知は観測した段階についてだけ語る。最終配送が復号成功を意味するとは限らない。Message-ID を保持できなければ照合も弱い。通知が正しく生成されても利用者が確認したとは限らない。報告、提示、聴取を同じ成功値にしてはならない。

実演は初版を保存せず、作り替えた

RFC 2421 は、EMA’96 の概念実証と EMA’97 の製品実演に基づくと記す。完全な参加企業一覧や成功率を示す資料ではないが、変更履歴は具体的である。

multipart/voice-message の内容は位置依存でなくなり、許容内容は明確に絞られた。転送と返信が定義され、ファクス、ディレクトリ情報、通知が拡張され、loopback は非推奨となり、セキュリティ記述が増えた。試験は初版を認証したのではなく、直すべき仮定を示した。

RFC 3801 は後に RFC 2421 を正式に廃止し、VPIMv2 をより精密に記述し直した一方、前文書からプロトコル変更はないとした。動作を変える改訂と、同じ動作の記録を明確にする改訂は、どちらも重要だが同じではない。

限定された通路だから検証できた

この歴史は音声メールが電子メールに吸収された話ではない。能力の違う装置が、失う意味を明示しながら共通の通路を作った話である。

完全な確認は、入力番号、FQDN 選択、DNS、SMTP 相手、EHLO、エンベロープ、識別子、追跡、MIME、転送符号、コーデック、サイズ、配送、保存、復号、受信箱、通知、再生、聴取を結ぶ。音声を受け取ったことは事実である。それだけでは、メールを覚えていたことにならない。

情報源