要約

  • RFC 3362 は、T.38 のリアルタイム・ファクス流を SDP で示す媒体サブタイプとして image/t38 を登録した。符号化そのものは ITU-T 勧告 T.38 が定義した。
  • 同じラベルを解釈できても、相手の受諾、転送方式の互換性、暗号化、ゲートウェイ変換、完全なページ受領は証明されない。

RFC 3362 の登録欄には、必須パラメータも任意パラメータもない。この簡潔さは、欠けた仕様を後で誰かが補うという意味ではなかった。ラベルが言えることを「この媒体は T.38 のファクス流である」に限定し、それ以外を別の仕様と実装に残したのである。

2002 年当時、IP 網へ移るファクスには複数の標準領域を結ぶ継ぎ目が必要だった。ITU-T 勧告 T.38 は、グループ3ファクス端末やゲートウェイが IP プロトコル上でリアルタイム通信するための技術を扱った。IETF の SIP と SDP は、セッションの確立と記述を担った。RFC 3362 は、その記述に共通名を与えた。

文書は符号化の所有者を曖昧にしない。定義は T.38 にあり、RFC はそこを参照する。T.38 はサービス環境に応じて TCP または UDP を利用できる。Annex D の SIP/SDP 手順は古い SIP 仕様を前提に書かれていたが、RFC 3362 は改訂版の RFC 3261 にも適用できると説明した。

この分担は、中央集権の不足ではなく、合成可能性の成果だった。ITU-T がファクス動作を定義し、IETF がセッション手順を定義し、IANA が識別子を保管する。実装者が採用し、運用者が結果を観測する。どの層も、自分の証拠以上の権限を主張する必要がない。

登録内容は二進データ、想定用途は common である。パラメータがないため、image/t38 だけを見ても、具体的なプロファイルや転送選択は分からない。二つの装置が同じ名前を知っていることと、同じ動作を選べることは別である。

用途の境界はさらに明確だった。この媒体型は SDP 内の T.38 ストリームを示すためのもので、電子メール用途ではない。メールでの使い方は定義されず、T.38 ストリームとの相互運用も保証されない。image という上位型から、添付ファイルとしての普遍的意味を推測してはならない。

セキュリティ欄も結論を急がない。対象は暗号化されている場合も、されていない場合もあるファクスのビットストリームである。ラベルは機密性を示さない。SIP 信号が保護されているか、媒体区間が暗号化されているか、変換後の区間で平文になるかは、具体的な経路に属する。

SDP は転送装置ではない。RFC 2327 から RFC 4566、現在の RFC 8866 まで、SDP はセッション記述形式であり、転送プロトコル自体を組み込まない。アドレス、ポート、媒体、形式を書けても、記述がパケットを運ぶわけではない。

相互運用の次の関門は offer/answer である。RFC 3264 では、一方の希望を offer として提示し、他方が answer で自分の希望を返す。完全なセッション像には両方が必要だ。相手はポートをゼロにして媒体流を拒否できる。したがって image/t38 を含む offer は、提案の証拠にすぎない。

answer が受諾しても、ページはまだ届いていない。両端で T.38 の動作が整合し、選んだ TCP または UDP が経路を通り、損失や遅延が許容され、ゲートウェイがパケット時間とファクス端末の期待を正しく変換する必要がある。セッション開始の成功とページ完了の成功は分離して記録すべきだ。

証拠の階段を作ると混同を避けられる。IANA レコードは登録を証明する。実装の能力一覧は認識を示す。SDP offer は提案を示す。answer は受諾または拒否を示す。パケット記録は転送を示す。ゲートウェイ・ログは変換処理を示す。ページ数と完了信号が技術的な到達を示す。人や業務が受け取ったかどうかは、その先の証拠である。

この階段を「対応済み」という一語で畳むと、どこで失敗したか分からなくなる。登録は普及率ではない。認識は受諾ではない。受諾は転送ではない。転送は完全なページではない。

媒体型登録制度も変化してきた。RFC 3362 の時代には RFC 2048 が手順を規定し、その後 RFC 4288、RFC 6838 が一般枠組みを更新した。審査と安定した命名は衝突を減らす。しかし登録手続きが装置へ機能を配布するわけではない。

RFC 2119 と RFC 8174 の要件語も同様である。仕様中の MUST は、準拠実装が満たす条件を明確にする。ある装置が特定時点で条件を満たしたという運用証明にはならない。そこには試験や観測が要る。

現在の IANA レコードが image/t38 と RFC 3362 への参照を保持していることは、長期的な調整の成果である。ただし、それが示すのは登録の継続性であり、現在のゲートウェイ数、暗号化率、転送方式、ページ成功率ではない。

本稿は Lu Heng の二つの論考を明示的な分析レンズとして用いる。「Minimum Initial Specification」は、共通層を必要最小限の検証可能な規則にとどめ、将来の採用を実行主体へ返す考え方を示す。RFC 3362 の細い継ぎ目は、その利点を具体化する。「On Reality Layers」は記録と実装結果を同一視しないよう促す。ここでは登録、提案、受諾、転送、受領が別の現実層となる。

ラベルは小さい。しかし小さいからこそ有効だった。それは標準間に共通の入口を作った。入口の先が通れるかどうかは、別の証拠で確かめなければならない。

出典