요약

  • 1994년 8월에 실험적(Experimental) RFC로 발표된 RFC 1664는 게이트웨이가 X.400과 RFC 822 주소를 매핑하는 데 사용할 수 있는 템플릿을 배포하기 위한 DNS PX 레코드를 제안했습니다.
  • PX는 주소 대응 관계를 기술하는 것이었습니다. SMTP MX 레코드가 메일 라우팅을 담당했고, PX도 이 RFC도 메시지가 실제로 전달되었거나 이 제안이 널리 배포되었다는 증거가 되지 않습니다.

전송이 아니라 번역을 위한 디렉터리

X.400 주소와 RFC 822 메일박스는 서로 다른 형식으로 표현하면서도 동일한 수신자를 가리킬 수 있었습니다. 두 체계 사이의 게이트웨이는 한 형식을 다른 형식으로 번역하는 규칙이 필요했습니다. 까다로운 부분은 메시지를 게이트웨이를 넘어 운반하는 것이 아니라, 게이트웨이가 사용하는 모든 곳에서 매핑 데이터의 일관성을 유지하는 것이었습니다.

RFC 1327은 이미 더 넓은 매핑 프레임워크를 규정하고 있었습니다. 그 전역 테이블에는 RFC 822 도메인과 X.400 조직 단위를 매핑하는 규칙이 포함되어 있었고, 최장 일치(longest-match) 동작이 게이트웨이가 관련 항목을 고르는 데 도움을 주었습니다. RFC 1664는 그런 매핑 정보를 배포하는 메커니즘을 제안했습니다. 타입 코드 26번을 가진 PX라는 새로운 DNS 리소스 레코드였습니다. 그 선호도(priority)와 매핑 필드를 통해 게이트웨이는 후보 대응 관계를 조회하고 로컬에서 적용할 수 있었습니다.

이 구분이 중요했던 이유는 DNS에 이미 메일 라우팅용 레코드가 있었기 때문입니다. RFC 1664는 SMTP 라우팅에는 MX를 사용한다고 밝히고, PX는 주소 매핑을 기술함으로써 그 정보를 보완한다고 설명합니다. PX 응답은 메시지도, 다음 SMTP 홉에 대한 경로도, 수신자 시스템의 수신 확인도 아니었습니다. 게이트웨이는 여전히 변환을 수행하고 관련 메일 프로토콜에 따라 전달을 처리해야 했습니다.

이 제안은 입증된 글로벌 서비스가 아니라 제한된 실험에서 나온 것이었습니다. 이 RFC는 일부 저자들이.itPTR 레코드에 매핑 데이터를 저장해 본 적이 있으며, 그 테스트가 소수의 응용에 유용했다는 점을 보고합니다. 또한 배포 비용도 짚습니다. 새 레코드 타입을 지원하려면 DNS 네임 서버에 수정이 필요했고, 인터넷의 이질적인 설치 환경 탓에 변경에는 시간이 걸릴 수밖에 없었습니다. 이 문서는 점진적으로 분산되는 X.400 네이밍 트리를 논의하고 별도의 배포 지침을 예고하지만, 이 부분은 완료되었다는 증거가 아니라 계획을 서술한 것입니다.

RFC 1664는 스스로를 실험적(Experimental)으로 표시하며 인터넷 표준이 아니라고 명시합니다. 이후 RFC 2163이 MIXER 지향 매핑 제안으로 이를 대체(obsolete)했습니다. 이 연속된 과정은 이후의 사양이 등장했다는 사실만 확립하며, PX가 널리 채택되었다는 증거가 되지 않습니다. 같은 시기의 RFC 1649의 운영 지침은 운영상 부담을 잘 보여줍니다. X.400/인터넷 서비스에 참여하는 게이트웨이는 전역적으로 일관된 매핑 테이블과 조율이 필요했습니다. 따라서 이 레코드의 역사적 의미는 DNS가 보편적인 X.400 디렉터리가 되었다는 증명이 아니라, 공유 번역 규칙을 어떻게 배포할 것인가라는 설계 문제를 명시적으로 드러낸 데 있습니다.

출처