要約

  • RFC 1277は、OSIネットワークサービスがない環境で、TCP/IPや一部のX.25網を介したOSI接続を試みるための情報を符号化した。
  • 世界で一意な形式はネットワークを識別し、転送パラメーターを運べたが、アドレスの割り当てだけで経路性やサービス応答が証明されたわけではない。

OSIディレクトリはプレゼンテーションアドレスを返せたものの、そのモデルはネットワークアドレスがOSIネットワークサービスから得られることを前提としていた。すべての実証環境がそうではなかった。OSIアプリケーションはインターネット、公衆または私設X.25網、独立したネットワーク上でも動いていた。実験のたびに全世界的なOSIネットワークサービスを待つなら、ディレクトリは試されている現場で役に立たなくなる。

RFC 1277が扱ったのは接続までの一工程だった。アプリケーションがプレゼンテーションアドレスを検索した後、クライアントはネットワークアドレスを取り出し、利用可能性と利用方法を判断し、優先順位を付け、接続を試す必要がある。このメモは取り出し処理に焦点を当てた。ディレクトリが別途返さない下位層情報をクライアントが推定できる符号化を定めたのであり、接続全体の手順、経路発見、アプリケーション交換の成功までは規定していない。

この線引きが重要なのは、アドレスが複数の役割を担ったからだ。国際X.25ではX.121形式のアドレスがDTEを識別し、条件が合えば公衆X.25網を通る経路にも使えた。しかし割り当て識別子は必ずしもトポロジー情報ではない。すべての全球割当部分が経路を表すと、エンドシステムは仮定できなかった。RFC 1277はIDPの主な目的は割り当てであり、原則として利用者はそこから経路を推定できないと説明する。特定のX.121形式を経路として扱う勧告も、利用するサービスと形式に依存し、私的な方法でより望ましい経路が見つかる場合もあった。

RFC 1006が定義したOSIトランスポートサービスを運ぶTCP/IP網向けには、RFC 1277は別の符号化を用意した。ネットワーク固有部の先頭は12桁のIPv4アドレスで、その後に5桁のポート番号と5桁のトランスポートセット値を任意で続ける。後者は16ビットのフラグ語で、TCPとUDPを表す値があり、省略時またはゼロなら既定値はTCPだった。RFCの例は10.0.0.6、ポート9、UDPを符号化する。これは接続を試すための解析規則であり、そのアドレスが今も有効、到達可能、待受中、または利用許可済みである証明ではない。

新形式は、OSIネットワークサービスで使う本来のアドレスとも区別しなければならなかった。RFC 1277がTelex AFIを選んだのは、より大きなドメイン固有部を残せ、ほかの用途との混同も比較的避けられるためだった。短いプレフィックスでサブネットを分け、残りにネットワーク固有情報を入れる。簡潔で自己記述的な構造を、長い十進表記と引き換えにした設計である。バイナリASN.1形式も魅力的だったが、利用可能なアドレス空間には収まらないとメモは記す。

これは過渡期の工学的な折衷であり、普遍的なアドレス原則ではない。メモの歴史的注記は、THORNとISODE/QUIPUプロジェクトで実装され、実行可能性が示されたと述べる。これはそのプロジェクトで提案が動いた証拠であり、広範な導入を示すものではない。後のRFC 1278は、人が表示を見る用途のプレゼンテーションアドレス文字列を定め、内部保存には使わないよう明記した。これはRFC 1277の割り当てと下位層符号化とは別の層である。RFC 1237のNSAP指針も、OSIコネクションレスネットワークサービスに関するもので、RFC 1277の非OSI下位層の課題とは異なる。

RFC 1277の教訓は「アドレスを見れば接続方法が分かる」より限定的だ。ディレクトリのレコードに、クライアントが下位層の解釈を選べるだけの構造を含めることはできる。それでも現行の経路、対応する待受側、成功したトランスポート交換、アプリケーション応答は別に必要だ。符号化値をそのすべての証明として扱えば、割り当て、解釈、到達可能性、サービスを一つの主張に潰してしまう。メモはそんな主張をしていない。

出典：RFC 1277、RFC 1006、RFC 1278、RFC 1237。