要約

  • Mary Ann HortonはUUCP Mapping Projectの組織化に携わり、各拠点の隣接情報を地域担当者が整え、各サイトが自分の配送表を計算できる公開データへ変えた。
  • この仕組みは、接続の存在、費用の評価、経路計算、ゲートウェイ、名前の登録を別々の責任として扱ったからこそ機能した。

duke!research!ucbvax!userという表記は、受取人だけでなく出発地からの道順も指定した。途中の計算機が電話をかけなくなれば、同じ文字列は役に立たない。相手までの経路は、技術だけでなく電話料金と管理者の協力に左右された。

Hortonが直面したのは、接続数が増えるほど利用者の知識では支えられなくなる逆説だった。解決は万能な中央地図ではなく、申告と査読と計算をつなぐ運用制度だった。

地図を大きくしても追いつかない

HortonはUSENIXのインタビューで、1982年と1983年にUsenetの論理図を会議で配ったと語る。参加者はメール経路にも使ったが、ニュース配送網と、より広いUUCPメール網は一致しない。見えないリンクは、好意で中継する拠点へ余分な負荷を集めた。

1984年には枝分かれが多すぎて、一枚の論理図では扱えなくなった。地理図と八ページの論理図が作られたものの、紙面の追加は更新責任を解決しない。新しい隣接関係を誰が受け取り、矛盾を誰が直し、いつ次の版を信頼するのかが本題になった。

リンクには値段もあった。大学が長距離通話を禁じる一方、企業の拠点が大きな請求を引き受けることもあった。片側からしか発呼しない回線、速くても接続頻度の低い回線、遅くても安定した回線は、図の一本線では区別できない。

地域ごとの手入れを仕組みにする

1984年1月、ワシントンのUSENIX会議で開かれた非公式会合からUUCP Mapping Projectが形になった。地域のボランティアがサイト情報と接続申告を集め、修正し、comp.mail.mapsで配布した。

参加者数の記録は時点が異なる。Stargateの回顧は初回に三十人超、Hortonの業績ページは約五十人のチームとする。さらに長期の地域協力者を広く数える記録もある。数字を一つにそろえるべきではない。

指導体制の記述にも差がある。Hortonは会合を招集し創設を率いたと回想する。2000年の終了草案は、USENIX資金による初期をKaren Summers-Hortonが率い、Hortonが1985年から運営したと記す。単独の創設者像よりも、複数の管理者が引き継げる制度の方が史料に合う。

RFC 850は公開情報の境界を示した。senduunameでUUCPの隣接先を集められるが、管理者は回答を編集でき、電話番号やパスワード、私的なダイヤル設定を送ってはならない。到達性の発見には隣接情報が必要でも、接続用の秘密までは要らない。

最小コストは運用者の判断だった

pathaliasを書いたのはSteve BellovinとPeter Honeymanである。接続を有向グラフにし、辺ごとに非負のコストとアドレス演算子を与え、Dijkstra法を応用してローカル拠点から既知の宛先への経路を事前計算した。

ただしコストは客観的な単位ではない。論文は電話料金、呼出頻度、速度、信頼性を挙げ、経験ある運用者が選ぶ経路に合うよう尺度を調整したと説明する。呼出確立や次回接続までの待ち時間は、公称速度以上に効くことがあった。

入力データも不完全だった。申告には矛盾や誤りがあり、ニュース図からの推定は接続を過少に表した。到達不能に見えるホストへ逆向きリンクを仮定する場合もあり、ドメインやゲートウェイには経験則が入った。最短経路は共有された真実ではなく、各サイトの実用的な見立てだった。

HortonはAdam Buchsbaumとsmailに取り組み、計算済み表を配送に使えるようにした。共同地図が可能性を示し、pathaliasがローカルな費用判断を行い、メーラーが実行する。責任を分けたことで、利用者はbang pathを暗記せずに済んだ。

名前は経路ではない

Hortonの「What Is a Domain?」は、ドメインの点が通過順序ではないと説く。ドメインは管理階層に属する絶対名であり、実際の次ホップは表、リゾルバー、ゲートウェイが決める。

RFC 819はドメインを命名権限と変換責任の範囲として定義し、相対的なUUCP源泉経路と対比した。RFC 920も、ドメインは管理主体であり、地理、トポロジー、機材、ソフトウェア、プロトコルの一致を必要としないと明記する。

Hortonの回想では、UUCP Projectは1986年にBITNET、CSNET、ARPANET側と共通名前空間へ参加した。業績ページは、直接インターネットへ接続しないUNIX組織150以上へ、1986年から1988年に.comや.eduのメールを提供したとする。これは本人の回顧値であり、本稿の独立集計ではない。

RFC 976は移行を実装面から示す。新たな規格を増やさず、既存のドメインとメール形式をUUCP zoneに採用し、ホストを能力別に分け、ゲートウェイへ高い互換性を求めた。短いuser@domainの裏では、表が依然として逐次経路を作っていた。

RFC 974のMXレコードは、名前と配送先の間にさらに再利用可能な層を置いた。管理者は優先メール交換機を変更し、故障ホストを避けられる。複雑さは消えず、利用者から管理された制御面へ移った。

終了を告知できること

2000年のプロジェクト終了草案によると、地図の利用減少を受け、データベースは同年8月に凍結された。古い地図を使えばメールの紛失や誤配送が起こり得るとも警告した。採択RFCではなく、運営側の終了記録として読むべき文書である。

保管されたファイルは、それだけでは現役のレジストリではない。更新を受け付け、異議を処理し、鮮度を示し、最後に信頼停止を宣言する人がいて初めて制御面になる。

現代の発見システムは自動化が進んだ。それでも、リンクを誰が主張し、負担を誰が引き受け、古い情報を誰が失効させるのかは自動では決まらない。Hortonの仕事が残したのは、地図よりも、その問いを運用可能にする責任の配置である。

情報源

  1. Wikimedia Commons：Mary Ann Hortonの2012年肖像
  2. UUCP Mapping Project終了草案
  3. UC Berkeley EECSの人物紹介
  4. Mary Ann Horton：業績
  5. Mary Ann Horton：インターネット史
  6. Stargate Internet Museum：UUCP Project
  7. Stargate Internet Museum：UUCPとメール
  8. Pathalias: The Care and Feeding of Relative Addresses
  9. Mary Ann Horton：What Is a Domain?
  10. RFC 1036：USENETメッセージ交換標準
  11. RFC 819：ドメイン命名規約
  12. RFC 850：USENETメッセージ交換標準
  13. RFC 920：ドメイン要件
  14. RFC 974：メール経路とドメインシステム
  15. RFC 976：UUCPメール交換形式
  16. USENIXによるMary Ann Hortonインタビュー