要約

  • RFC 1486 は国際電話番号の数字を逆順の DNS ラベルに変換し、tpc.int 配下の MX 経路で遠隔印刷サーバーを選んだ。
  • ワイルドカード MX は番号帯を扱う意思を示すだけで、個別番号の有効性や G3 ファクシミリ装置の接続を証明しないと仕様自身が警告した。
  • メール受理、内容変換、電話接続、FAX 送信、紙への出力、本人の閲覧は異なる完了点である。成功通知も人の受領までは届かなかった。

「成功」の主語を探す

1993 年の遠隔印刷実験は、結果を何も返さない仕組みではなかった。RFC 1486 は処理後に成功または失敗のメッセージを差出人へ返すよう求めた。後継の RFC 1528 は成功を、メッセージがファクシミリ装置へ正常に送られた状態と説明した。応答がなければ、複数回の試行後に失敗理由を返せた。

これは実運用に必要な改善だった。Message-ID を手掛かりに、投入したメールと下流の結果を対応づけられる。しかし「装置へ送った」と「人に届いた」は同じではない。共有 FAX の用紙切れ、印字不良、放置、部屋の移転、番号の再割当ては、ゲートウェイの観測外にある。

RFC Editor の記録 によれば RFC 1486 は 1993 年 7 月の Experimental 文書である。同年 10 月に技術手順と管理方針へ分割された。RFC 1528 の記録 と RFC 1529 の記録 は、その継承関係と異なる文書上の地位を示している。

数字を逆さにして委譲へ合わせる

実験は電話番号をメールアドレスのドメイン部に変えた。たとえば国番号から始まる番号の記号を除き、数字を逆順にし、一桁ずつ DNS ラベルにして tpc.int の下へ置く。ローカル部は remote-printer だった。

逆順は奇抜な飾りではない。電話番号の国・地域・交換局・加入者という階層を、DNS が右から左へ細分化する委譲方向へ合わせる工夫だった。遠隔印刷サーバーは、扱える番号プレフィックスにワイルドカード MX を置けた。複数サーバーが同じ範囲を扱うなら複数 MX も使える。

メールは RFC 974 の MX アルゴリズムに従い、RFC 1034 と RFC 1035 の DNS 機構を利用した。キャッシュや優先度、委譲という既存資産をそのまま借りられた反面、古い回答や不完全な回答のリスクも引き継いだ。

そして仕様は限界を隠さなかった。ワイルドカード RR が一致しても、その電話番号が有効とは限らない。有効な番号でも、そこに G3 FAX が接続されているとは限らない。DNS が表すのはゲートウェイの範囲に対する意思であって、端末台帳ではない。

MIME は印刷可能性を交渉しきれなかった

送信側は RFC 822 メールを作り、Message-ID と MIME multipart を使えた。application/remote-printing 部は表紙情報を持ち、別の部が印刷対象を持つ。RFC 1341 の MIME は、plain text、埋め込みメール、PostScript、TIFF、multipart という異なる内容を一つのメール基盤に載せる道を与えた。

だが型が付いたことは、装置が確実に印刷できることを意味しない。文字集合を持たないプリンターもあり、PostScript は安全な実行環境を要し、multipart/alternative ではどの表現を選ぶか決めなければならない。RFC 1486 自身も、対応する内容型や文字集合を事前に決定する仕組みを未解決事項に残した。

宛先のローカル部に付けられる不透明文字列は、表紙上の氏名や部屋を作るための便宜だった。それは本人確認でも組織ディレクトリでもない。美しく印刷された宛名は、入力者がそう書いたという事実以上の権限を持たない。

経路の背後にある負担

MX が返っても、誰かが電話料金、装置、保守、迷惑送信を引き受ける必要がある。RFC 1529 は、地域機関が共同サービスとして負担する方式、商店型の契約サービス、広告主が支える新聞型などを示した。同じアドレス構文の背後に、異なる経済関係が存在し得た。

当時は広範な認証基盤がなく、文書は送信者を確実に識別できないと認めた。そのため受信者へ一方的に課金することは不適切とされ、送信元による拒否、監査ログの上限、内容と通信パターンのプライバシーが管理問題となった。

DNS の委譲は、これらの制度を承認しない。MX 優先度も、誰が費用を負担すべきか決めない。技術手順と管理方針を別 RFC にしたことは、共通の到達方法とローカルな権限判断を混同しない設計でもあった。

名前が消える時にも実装を見る

2023 年の RFC 9121 は、インフラ用途の .int 名が実際には旧式化したと記録した。tpc.int はメールと FAX の橋として説明され、RFC 1528 は Historic へ変更され、関連名は .int ゾーンから削除された。判断材料には文書の古さだけでなく、DNS 問合せの少なさと関係者への確認が含まれた。

廃止は実験の価値を消さない。同時に、RFC が存在することを稼働証明にもできない。古いクライアントが名前を固定していれば、削除後の失敗や将来の再利用リスクが残る。名前空間の終了にも、実装と観測に基づく移行が必要である。

Heng Lu の稼働コード優先、最小初期仕様と将来判断の局所化、現実の層という議論は、この実験の寸法を保つ。共通層は番号変換、メール経路、内容形式を扱った。ゲートウェイ運用者は範囲、拒否、費用を決めた。電話網と FAX は別の実行証拠を残し、人の受領はさらに別だった。

保存すべき台帳は、元番号、変換規則、DNS 応答と TTL、選択 MX、SMTP 応答、Message-ID、内容ハッシュ、変換結果、ゲートウェイ方針、呼出し履歴、FAX セッション、返送通知を分ける。重大な通知なら、最後に人間側の受領証拠を加える。

RFC 1486 の成功は、メールが紙を完全に支配したことではない。「成功」という短い語に、どこまでが観測済みかを残したことである。

情報源