要約

  • RFC 1394 は地域名、電話国番号、テレックス国番号、answerback、Internet ドメインを、時点のある対照表として並べた。同行であることは関連の主張であり、稼働証明ではない。
  • 不明は消されなかった。電話番号用とその他の項目用に異なる欠落表示があり、誤りの可能性を明記し、郵便・電子メール・テレックスで訂正を募った。
  • 正しいコードでも、DNS 委任、利用可能で許可された回線、相手の真正性、配送、国家承認までは証明しなかった。

表は通信網を一つにしなかった

RFC 1394 が1993年1月に公開されたとき、利用者は同じ場所について複数の記号を使い分けていた。電話の国番号は知っていてもテレックスの answerback が分からない。Internet の国別ドメインは見覚えがあっても、公衆メール網の入口を知らない。文書はその摩擦を減らそうとした。

各行には名称、電話国番号、テレックス国番号、answerback、Internet ドメインが置かれた。米国の州ドメインや商用メールシステムも含まれる。地理、通信番号、階層名、事業者の名前が一つの探索面に集められたことになる。

しかし、列ごとの作用は違う。電話番号は交換網が解釈する。テレックスの値は別のサービスで使われる。ドメインは名前空間の位置を示す。事業者のメール名は領土ではなくサービスを指す場合がある。同じ行は相互参照を助けても、どの網でも実行できる変換命令にはならなかった。

空欄にも来歴があった

RFC 1394 は、電話国番号が不明な場合と、その他の情報が欠ける場合に別のダッシュ表示を使った。欠落を一種類に潰さなかったことで、「存在しない」「把握していない」「資料にない」を安易に同一視する余地を減らした。

一覧には複数値や別名も多い。一つの地域に複数のテレックス番号があり、旧称と新称が同じドメインへ向かい、ドメインはあっても answerback が記録されない行もある。旧国家、領域、地域、私設網が併記されたのは検索上の必要からであって、同じ法的・技術的性質を与えるためではない。

作成者は情報が複数の国と情報源から集められ、正確性を保証できず、一部のコードは誤っている可能性があると記した。訂正は郵便、電子メール、テレックスで受け付けた。これは保守の窓口を持つ刊行物であり、各通信網と自動同期する台帳ではない。

従って、重要な判断に使うなら、掲載値の時点、出典、担当者、そして当該システムでの再確認が要る。丁寧な編集は時点のある観察を強くするが、永久の権威には変えない。

二文字はルートへの委任ではない

RFC 920 は国別トップレベル名に ISO 3166 の英字二文字コードを使う方針を示していた。同時に、利用可能なラベル、ドメインの設置、管理者とエージェントの公表を分けていた。コードが存在しても、DNS にその枝が設置済みとは限らない。

RFC 1034 では、DNS の権威はゾーンごとに区切られる。ネームサーバーが権威を持つのは木の限定された範囲であり、他の範囲について非権威のキャッシュを持つこともある。委任には親子ゾーンの切れ目のレコードと、子のサーバーへ到達するための情報が必要だ。

RFC 1394 の欄に二文字を印刷しても、その切れ目は作られない。管理者も選ばれず、サーバーの応答も確認されない。委任の証拠は権威ある親ゾーンから、稼働の証拠は時点を定めた問い合わせから得なければならない。

逆も同じである。ccTLD が応答したからといって、隣に載った電話やテレックスの値まで最新とは限らない。列ごとに管理主体と時計が違う。

ドメインの形をしたゲートウェイ記法

BITNET と UUCP に関する注記は、文字列の外見だけでは不十分だと示す。System.BITNET と host.UUCP は各コミュニティ内で使われたが、DNS 登録名ではなかった。Internet からのメールは、パーセント記法で Internet/BITNET または Internet/UUCP ゲートウェイへ渡し、そこで変換する必要があった。

末尾に点付きの名前があっても、次の処理は DNS 解決ではない。変換規則と転送能力はゲートウェイが持つ。ゲートウェイが受理した事実は中継の開始を示すだけで、遠隔システム、メールボックス、受取人への到達は別の観察になる。

一方、同文書は .ARPA をホストとネットワークの逆引きに使う歴史的な DNS 領域として説明した。似た構文の背後に、権威委任、コミュニティ慣行、ゲートウェイ命令という別々の仕組みがあった。

接続可能性と許可は別の条件だった

RFC 1394 は、ある国へ到達できるかどうかは接続の有無と接続が許されているかに依存すると明記した。政治的理由による制限も例に挙げている。

ここで表の対応、運用経路、許可が分離される。コードが正しくても、発信地点から経路がないことはある。物理的な経路があっても、政策や契約が利用を禁じる場合がある。経路も許可もあって、特定の宛先が存在しないこともある。

無応答だけではどの層が原因か決められない。古いコード、停止したゲートウェイ、経路障害、規制、宛先拒否は同じ沈黙を生む。沈黙から国やドメインの有効性を裁くことはできない。

成功も範囲が狭い。一度の接続は、その時点で何らかの経路が交換を完了した証拠である。相手の人格を自動的に認証せず、将来も接続できる権利を作らない。

収録は国家承認ではなかった

RFC 1394 は、国の名称や存在の正当性について立場を示さないと明言した。旧称と別称を募ったのは、異なる時代の語を持つ利用者が同じ項目へ辿れるようにするためであり、外交判断のためではない。

旧国家、領域、下位地域、商用網が混在する一覧では、この抑制が不可欠だった。資料に現れた呼称を残すことと、その政治的地位を承認することは違う。編集上の訂正に憲法的な意味を持たせれば、探索道具は維持できなくなる。

後の RFC 1591 はトップレベルドメインの委任と指定管理者の責任を記述した。ccTLD 管理者には運用能力と管理・技術連絡先が求められ、地域と世界の Internet に対するサービス責任がある。同時に、IANA は何が国であるかを決める機関ではなく、その手続を持つ ISO 3166 を基礎にしたと説明した。

ここでも責任は分配される。コード表の維持、ルート委任、ドメイン運用、通信の輸送、公法上の判断は別の主体に属する。一つの担当を持つ者が全体の主権を得るわけではない。

薄い対照表は次の確認先を示した

RFC 1394 はセキュリティを論じていない。各行の認証、連絡への同意、ゲートウェイでの送信者保存、最終配送を保証しなかった。その欠落は、文書を無価値にするのではなく、用途を限定する。

役割は次の問いを作ることだった。どのコードを誰に確認するか。接尾辞は本当に委任されているか。どの応答が権威あるものか。ゲートウェイと経路は生きているか。利用は許可されているか。宛先は受理したか。

対照表が最終判断を装わず、次の証拠へ案内する限り、共通層は薄く有用でいられる。