요약

  • RFC 1278은 프레젠테이션 주소(셀렉터와 하나 이상의 네트워크 주소)에 대한 사람이 읽을 수 있는 문자열을 정의했지만, 이 형식이 내부 저장용으로 의도되지 않았음을 명시적으로 밝혔다.
  • 편의를 위해 RFC 1006 입력으로 DNS 이름을 사용할 수 있었다. 그 이름이 여러 IP 주소를 산출하면 결과는 여러 네트워크 주소가 되어야 했고, 인코딩된 주소를 다시 표시할 때는 IP 형식이 요구되었다.
  • 재귀 매크로는 긴 주소를 읽기 쉽게 만들었지만, 이 문서는 어떤 매크로도 절대 의존해서는 안 된다고 명시했다. 표시 값, 확장 사전, DNS 응답, 인코딩된 주소 집합, 경로 선호, 연결 시도는 서로 다른 기록으로 남았다.

두 번째 데이터베이스가 아니라 표시 표면

RFC 1278은 1991년 11월에 Informational 문서로 등장했다. 그 임무는 소박해 보인다. OSI 프레젠테이션 주소의 문자열 인코딩을 정의하는 것이다. 이 소박함이 중요한 이유는 그 밑에 있는 대상이 단일 호스트 레이블이 아니었기 때문이다.

프레젠테이션 주소는 논리적으로 프레젠테이션 셀렉터, 세션 셀렉터, 트랜스포트 셀렉터, 그리고 네트워크 주소 집합을 포함했다. 셀렉터들은 편리한 문자 형태를 가질 수도 있는 옥텟 문자열이었다. 네트워크 주소들은 여러 주소 패밀리에 속할 수 있었다. 따라서 하나의 애플리케이션 엔티티는 하나 이상의 후보 경로를 통해 도달할 수 있었고, 셀렉터들은 그 위쪽 계층의 만남 지점을 이름 짓는 역할을 했다.

표준 디렉터리 표현은 ASN.1이었다. RFC 1278의 문자열은 사람, 보통 시스템 관리자에게 표시하기 위한 것이었다. 이 문서는 주소를 표시해야 할 때 이 형식을 권장했지만, 내부 저장용으로 의도되지 않았다고 직접 밝혔다.

이 한 문장이 흔한 아키텍처적 붕괴를 막는다. 표시 값은 복사되거나, 짧아지거나, 지역화되거나, 순서가 바뀌거나, 내일은 사용할 수 없는 사전으로 렌더링될 수 있다. 저장되는 표현은 나중에 해석하는 데 필요한 것을 보존해야 한다. 둘을 닮게 만든다고 해서 수명이나 권위까지 같아지지는 않는다.

문서의 요구 사항은 이 균형 잡기를 드러낸다. 문법은 모든 합법적 값을 표현하고, 셀렉터가 없을 때 깔끔하게 유지하며, 문자·십진수·숫자·16진수 셀렉터 인코딩을 지원하고, TCP/IP와 X.25(80)를 수용하며, 확장이 가능하고, 합리적으로 간결해야 했다. 가독성은 불편한 사례들을 버림으로써 달성되지 않았다.

한 줄이 주소 집합을 담을 수 있었다

문법은 선택적 프레젠테이션·세션·트랜스포트 셀렉터를 네트워크 주소 목록 앞에 배치했다. 여러 네트워크 주소는 문자열 안에서 결합되었고, 조용히 하나의 선호 경로로 축소되지 않았다.

이 세부 사항이 중요한 이유는 다중성이 곧 증거이기 때문이다. 집합은 여러 후보가 프레젠테이션 주소에 속한다고 말한다. 사용 시점에 동시에 도달 가능하거나, 선호도가 동일하거나, 하나의 엔드포인트에 묶여 있다고는 말하지 않는다.

인접한 주소 인코딩 사양인 RFC 1277은 운영 절차를 명확히 만든다. 먼저 시스템은 OSI 디렉터리에서 애플리케이션 엔티티를 조회하고 프레젠테이션 주소를 얻는다. 다음으로 각 네트워크 주소를 추출하고 사용 가능한지와 어떻게 사용할 수 있는지 판단한다. 그런 다음 후보들에 순서를 매긴다. 이 단계들을 거친 뒤에만 하나 이상의 연결을 시도한다.

RFC 1278은 이 복합 기록을 표시하고 입력하는 방법을 제공했다. 추출을 수행하거나, 경로를 선택하거나, 성공한 세션을 기록하지는 않았다. 유효한 문자열은 상류의 증거였지, 그것이 묘사하는 경로의 결과물이 아니었다.

도메인 이름은 입력 편의 기능이었다

RFC 1006 형식은 점으로 구분된 IP 주소 또는 DNS 도메인 이름을 담을 수 있었다. RFC 1278은 이 비대칭성을 설명했다. 도메인 이름은 주로 입력을 쉽게 하기 위해 존재했다는 것이다.

그 이름이 여러 IP 주소로 매핑되면, 여러 네트워크 주소가 생성되어야 했다. 소프트웨어가 인코딩된 주소를 다시 문자열 형식으로 변환할 때는 항상 IP 주소 형식을 사용해야 했다.

이것은 작지만 정확한 출처(provenance) 규칙이다. 입력된 이름은 하나의 기록이다. 운영자가 제공한 것이다. DNS 응답은 또 다른 기록이다. 어느 시점에 해석이 반환한 것이다. 생성된 주소 집합은 세 번째 기록이다. 인코더가 그 관찰로부터 만든 것이다. 저장된 값을 나중에 표시할 때 조용히 DNS를 다시 조회해서 오늘의 답을 어제 수락한 주소 집합인 것처럼 보여서는 안 된다.

이 규칙은 카디널리티도 보존한다. 하나의 편리한 레이블은 여러 경로 후보를 산출할 수 있다. 레이블만 저장하면 DNS가 바뀔 때마다 이전 기록의 의미가 움직인다. 임의로 선택한 IP 하나만 저장하면 해석이 실제로 만든 집합이 지워진다. RFC 1278의 방향은 편의 기능을 명시적인 네트워크 주소들로 전개하는 것이었다.

그렇다고 생성된 모든 주소가 작동한다고 주장하지는 않았다. DNS 출력은 연결 영수증이 아니었고, IP 리터럴은 인증된 엔드포인트 신원이 아니었다. 정규화는 입력 변환을 검사 가능하게 만들었을 뿐이다.

매크로는 의미를 압축할 수 있었지만 소유하지는 않았다

길고 구조화된 주소는 사람의 눈에 적대적이다. 그래서 RFC 1278은 앞에 토큰과=를 붙여 흔한 주소 접두어를 대신할 수 있게 허용했다. 확장은 재귀적일 수 있었다. 짧은 로컬 매크로가 더 넓은 매크로를 포함할 수 있었고, 결합된 결과가 전체 주소를 만들어낼 수 있었다. 주소를 사람에게 표시할 때 소프트웨어는 사용 가능한 가장 긴 치환을 사용하도록 되어 있었다.

표시 규칙은 인식을 최적화했다. 익숙한 짧은 형식은 운영 주소를 비교하거나 입력하기 쉽게 만들 수 있었다. 그러나 압축은 별도의 사전에 대한 의존성을 만들었다. 매크로가 바뀌거나, 사라지거나, 다른 시스템에서 다르게 해석되면 같은 보이는 토큰이 더 이상 같은 주소를 재구성하지 못할 수 있었다.

RFC 1278은 이 위험을 제안된 표준 매크로 목록 뒤로 숨기지 않았다. 어떤 매크로도 절대 의존해서는 안 된다고 명시했다. 제안된 이름들은 인터페이스상의 편의였지, 지속적인 레지스트리 계약이 아니었다.

이것이 이 글의 중심 경계다. 매크로 사용, 매크로 정의, 재귀 확장, 확장된 네트워크 주소는 네 개의 서로 다른 기록이다. 나머지 셋이 계속 사용 가능할 것이라고 가정한 채 첫 번째만 보존하면, 표시 정책이 숨겨진 상태로 변한다. 내구 저장 전에 확장하면 의존성이 보이는 상태로 남는다.

혼합 네트워크가 정밀함의 이유였다

RFC 1277은 이 문자열이 왜 이렇게 넓은 범위를 커버해야 했는지 설명한다. OSI 애플리케이션은 국제 및 사설 X.25 네트워크, 고립된 OSI 네트워크, CLNP 파일럿, 고립된 TCP/IP LAN, 그리고 RFC 1006을 통한 DARPA/NSF 인터넷 위에서 동작하고 있었다. 단 하나의 보편적인 OSI 네트워크 서비스에 의존하는 것은 실용적인 전제 조건이 아니었다.

RFC 1277의 임시 방식은 소프트웨어가 네트워크를 식별하고 트랜스포트 아래에 필요한 정보를 추출할 수 있을 만큼의 하위 계층 정보를 네트워크 주소 안에 인코딩했다. 디렉터리 조회, 해석, 선호 결정, 연결 시도는 별개의 단계로 남았다. 이 형식은 이기종 시스템이 밑에 있는 네트워크들이 하나가 되었다고 주장하지 않으면서 공통 주소 표면에서 만나도록 도왔다.

RFC 1278은 그 복잡성 위에 운영자에게 하나의 읽기 쉬운 문법을 제공했다. 그 성공 조건은 충실한 표현이었지, 보편적 도달 가능성이 아니었다. 주소는 문법상 합법이면서도 특정 호출자에게는 사용 불가능할 수 있었다. 후보는 사용 가능하면서도 선호도가 낮을 수 있었다. 시도된 연결은 실패할 수도 있었다. 그 어떤 후속 상태도 원래의 표시 기록을 다시 쓰지 않았다.

출처가 확립하는 것

이 글은 사람 표시 목적, 셀렉터 및 주소 목록 문법, RFC 1006 DNS 입력, 다중 주소 확장, IP 출력 정규화, 재귀 매크로, 명시적 비의존 경고에 대해서는RFC 1278을 사용한다. 인접한 하위 계층 맥락과 디렉터리 조회에서 추출, 선호 결정, 연결 시도에 이르는 절차에는RFC 1277만을 사용한다.

두 문서 모두 보안 고려 사항을 논의하지 않았다고 밝힌다. 두 문서는 표시된 주소가 엔드포인트를 인증한다거나, 매크로가 신뢰되거나, DNS 결과가 안정적이거나, 경로가 승인되었거나, 연결이 성공했다고 확립하지 않는다. 두 문서는 사양과 일부 RFC 1277 구현 맥락을 보고할 뿐, 배포 현황 조사나 현재의 운영 권고가 아니다.

역사적 성취는 표면들 사이의 규율 있는 번역이다. RFC 1278은 복합 주소를 읽을 수 있게 만들었지만, 편의 기능이 내구 저장이 되기 전에 그 위장을 벗도록 요구했다. 매크로는 사람을 도울 수 있었다. 저장된 주소는 매크로를 초과해서 살아남아야 했다.