要約

  • 1982年1月11日にISIで開かれた会合は、username @ hostnameをusername @ host.domainへ拡張する方針を選んだ。新しい階層は一つだけある@の右側に収め、利用者名に点を使う既存システムにも手を付けなかった。
  • 上位ドメイン名の世界的な一意性や検索結果の種類を定める必要があった。ホスト欄の点をソフトが受け入れ、いつからネットワーク全体で送ってよいかを決める作業も残った。

古い郵便局の棚を思い浮かべたい。左側の引き出しには各部署が好きな作法で名前を書いている。Sato.Kという札もある。そこへ増築業者が来て「新館のために古い札も全部書き直します」と言えば、郵便係は図面より先に配達不能票を心配するだろう。Jon PostelのRFC 805は、1982年1月11日にISIで行われたコンピュータメール会合を記録する。増築先に選ばれたのは@の右側だった。

会合には、もっと整った構想もあった。unique-id @ location-idなら、メールボックスの恒久的な身元と現在の届け先を分けられる。場所が変わっても同じ身元を使える。しかし現実の書き方はすでにuser @ hostであり、user欄にはシステムごとの変種が多かった。きれいな全体設計のために、各地の動くプログラムへ改修費を押し付ける案は棚上げされた。

階層を@の左に置く案も、右に置く案も検討された。含められる情報は同じでも、壊すものが違う。既に利用者名の中で点が使われている以上、その点を世界共通の階層区切りと読み直せば、昨日届いた宛先が今日から怪しくなる。そこで新しい階層はホスト側だけに置いた。@は一個、右側の節点は点で区切り、具体的なものから一般的なものへ並べる。例はPostel @ F.ISI.IN。上位の名前には世界的な一意性が必要で、選定には管理が要る。地図は共有し、個々の引き出し名は現場に任せる設計である。

会合は名前を引くだけでも仕事を三つに分けた。属性から人を探す「白いページ」、恒久的な身元から現在地を求める処理、所在地から数値アドレスを得る処理だ。差し迫って必要なのは最後の仕事だった。問い合わせへの返答には最終的なホスト、下位の名前サーバー、転送先という種類がある。次の窓口を示す返事を、配達先そのものと取り違えては困る。階層名は絶対的な宛先、ソースルートは相対的な経路とも整理された。NCP/FTPとTCP/SMTPが並ぶ時代には、メールサービスの情報も無視できなかった。

実装案は一つに決まっていない。FTPで読めるテキストファイル、TCPに似た接続やUDPデータグラムによる問い合わせ、最初の中央サーバー、後のドメイン別管理と複製が議論された。RFC 805にあるのは選択肢であり、後年の名前システムがこの会合で完成したという記録ではない。当面はRFC 733や移行計画、SMTP関連の文書を直し、ホスト欄の点をプログラムが読めるようにする仕事があった。

ここで目を引くのは、名前を決める会議が同時に「誰が何を決めるか」も分けていたことだ。上位ドメインの重複は遠くの相手まで巻き込むので、共通の管理が欠かせない。一方、個々のユーザー名にまで同じ担当者が口を出せば、既存の住所が改名騒ぎになる。検索結果にも、届け先と次の問い合わせ先という区別を要求した。名前の階層だけ整えても、判断の階層が曖昧なら郵便は止まる。

さらに開始日の問題が残る。DARPAのDuane Adamsには、点を含むホスト名をARPANETとInternet全体へ送っても受信側が異議を唱えなくなる日付を決める仕事が割り当てられた。期限は1982年3月1日。記録は課題と期限を示すが、その日に移行が終わったとは述べない。新しい住所を印刷できることと、向こうの郵便係が読めることは別々の出来事だ。

一見地味な@の境界が、多くの改修を減らした。左の名前を持つのは現場、右の所在地を揃えるのはネットワーク。増築工事はそれで進められる。開館日だけは、図面ではなく人と機械の都合を合わせて決めなければならなかった。