要約

  • RFC 1278 は、複数層の selector と一つ以上の network address を含む Presentation Address を人が扱うための文字列表現を定め、内部保存用ではないと明記した。
  • RFC 1006 形式では入力の便宜のため DNS 名を使えたが、複数 IP が返れば複数の network address を生成し、保存済みアドレスの再表示には IP 形式を使うことにした。
  • マクロは再帰展開と最長置換を許した一方、依存は禁止された。省略名、辞書、DNS 観測、生成集合、候補順位、接続試行は別々の記録である。

表示形式には保存形式と異なる寿命がある

1991 年 11 月の RFC 1278 は Informational 文書であり、Presentation Address の文字列表現を定めた。対象は単なるホスト名ではない。論理上の Presentation Address には presentation selector、session selector、transport selector と network address の集合が含まれる。

selector は octet string であり、文字で読める場合もあれば、十進、数値、十六進で表す必要もある。network address も一種類ではなかった。一つの Application Entity が複数の候補を持ち、上位層の会合点を selector が指定する。

OSI Directory に保存される標準表現は ASN.1 だった。RFC 1278 の文字列は人への表示、主に system manager の操作面を意図し、内部保存には使わないと明言する。

表示は、認識しやすさのために短縮やローカルな辞書を使える。保存は、将来その辞書がなくても意味を回収できなければならない。両者を同じ欄に入れると、見た目には一つでも、解釈の責任は外部環境へ移る。

要件は複雑さを隠さない。すべての合法値を表せること、selector がない一般例では簡潔であること、複数の selector encoding、TCP/IP と X.25(80)、追加形式への拡張性、適度な短さが同時に求められた。

一つの表記が複数候補を保持する

文法は三種類の selector を network-address-list の前に置く。list は一つに限られない。人が読む一行の中に複数候補を残す設計である。

候補集合は、到達可能性の結論ではない。それぞれが同時に使えるとも、同じ優先度とも、認証された同一相手とも限らない。

RFC 1277 は、運用上の順序をさらに分ける。OSI Directory から Application Entity を検索して Presentation Address を得る。そこから各 Network Address を取り出し、利用可能性と利用方法を判断する。次に優先順位を決め、最後に一つ以上への接続を試す。

RFC 1278 の文字列は最初の複合記録を読めるようにする。address の利用判定、順位、接続結果はまだ存在しない。構文検査が通ったことを、経路検証やセッション成立に読み替えることはできない。

DNS 名は入力時の便宜だった

RFC 1006 形式では、点付き IP だけでなく DNS domain name も入力できた。ただし RFC 1278 は DNS 名を主に入力の容易さのためと位置づける。

一つの名前が複数 IP に対応するなら、複数の network address を生成する。符号化済みアドレスを文字列へ戻す場合は、常に IP address 形式を使う。

この非対称性は履歴を守る。operator が入力した名前、ある時点の DNS 応答、そこから生成された address set は同一ではない。保存値を表示するたびに DNS を引き直せば、今日の応答が昨日の物化結果を上書きする。

名前だけを保存すれば過去のレコードが DNS とともに動く。IP を一つだけ選べば、その時点で得た複数候補が消える。RFC 1278 は便宜入力を明示的な address set に変える方向を選んだ。

それでも IP literal は相手の本人性ではない。DNS 応答も接続 receipt ではない。正規化が保証するのは、入力変換を後から検証できることまでである。

マクロ辞書をインフラにしない

長い構造化アドレスは読みにくい。そこで RFC 1278 は、= の前の短い token を共通 prefix のマクロとして扱った。マクロは別のマクロを含められ、完全なアドレスまで再帰展開できる。表示では最長の利用可能な置換を選ぶ。

短い表記は比較と入力を助けるが、意味は別の辞書に移る。辞書が変わる、別 host にない、再帰途中の定義が異なる、といった条件で同じ token の復元結果は変わる。

RFC 1278 は推奨マクロを列挙しながらも、どのマクロにも依存してはならないと書いた。推奨された表示語彙は、永続的な registry の約束ではなかった。

マクロ token、定義、展開過程、完全 address は別記録である。token だけを保存すると、見えない依存関係が後世の decoder を支配する。保存前の展開は、単なる実装細部ではなく provenance の確定である。

混在する下位ネットワークを一つに見せすぎない

RFC 1277 が描いた背景には、国際および private X.25、孤立した OSI network、CLNP pilot、RFC 1006 を使う TCP/IP LAN、DARPA/NSF Internet が並存していた。普遍的な OSI Network Service を待つことは実用的ではなかった。

そこで下位層を判断する情報を Network Address へ符号化し、directory lookup の後に algorithm で解釈した。RFC 1278 はその異質な address を一つの可読文法に載せた。しかし文法の共通化は、下位 network の統合でも、route の成立でもない。

globally unique な構文も authentication ではない。利用可能性、priority、attempt、session は後続状態である。表示文字列を所有する operator が、それら全てを制御するわけでもない。

根拠と限界

本稿は RFC 1278 から、人向け表示、selector と address list、DNS 入力、複数 address 生成、IP 出力、再帰マクロ、非依存規則を確認する。RFC 1277 は、混在する下位 network と、lookup、抽出、順位付け、接続試行の分離を説明する補助資料としてのみ使う。

両文書とも security considerations を議論しない。macro の信頼性、DNS の将来安定性、address の認証、route の許可、connection の成功、現代の普及状況は証明しない。

RFC 1278 は複雑なアドレスを人が扱える形にした。同時に、その形が消えても保存記録が残るよう、便利な表面を権威にしなかった。省略形を長生きさせるのではなく、完全なアドレスを省略形より長く生かす設計だった。