요약

  • RFC 7451의 후속 제안안은 EPP 확장이 최소 한 쌍의 레지스트리/레지스트라 또는 서버/클라이언트에 의해 구현·배포되었다면 지정 전문가가 관용적으로 검토하도록 규정한다. 또한 동일하거나 유사한 기능을 가진 여러 확장이 등록될 수 있으며, 유사성만으로는 그 외 유효한 요청을 거부할 이유가 되지 않는다고 명시한다.
  • 따라서 등록은 내구성 있는 사양과 식별자, 그리고 책임 소재가 있는 검토 경로를 확립한다. 선호 설계를 선정하거나, Standards Track 지위를 부여하거나, 폭넓은 채택을 입증하거나, 두 구현이 상호운용됨을 증명하지는 않는다.
  • 운영 중인 IANA 레지스트리는 이미 공존을 보여준다. 주석에 따르면 CORE와 TANGO의 IDN 확장, 그리고 두 회사의 개인정보 보호 확장은 서로 다른 XML 네임스페이스를 사용하면서 구문·기능 면에서 동일하다. 운영자는 이 중첩을 어디서나 타당한 '동등함' 주장으로 바꾸지 않고 기록하는 공존 지도가 필요하다.

레지스트리 표는 낯익은 데다 위험한 독법을 부른다. 각 행은 하나의 이름, 하나의 참조, 하나의 상태를 가진 순위 후보처럼 보인다. 두 행이 같은 기능을 다룰 때, 어느 쪽이 이겼는지 묻고 싶어진다.

그 질문은 조정 기록을 제품 판정으로 오인한다. EPP 확장 레지스트리가 존재하는 이유는, 확장 가능한 프로비저닝 프로토콜(EPP)이 기본 명령과 객체 매핑을 넘어 성장하도록 설계되었기 때문이다. 레지스트리, 레지스트라, 소프트웨어 공급자는 핵심 사양이 정하지 않는 운영상 필요를 위해 새 프로토콜 요소를 도입할 수 있다. 공개 카탈로그는 이러한 추가 항목을 찾을 수 있게 하고 식별자에 안정적인 소속을 부여한다. 그렇다고 여러 답을 낳은 기관적 역사가 지워지지는 않는다.

이 구분은 RFC 7451을 대체할draft-ietf-regext-ext-registry-epp-10에서 이제 명시적이다. 이 초안은 검토자에게 동일하거나 유사한 기능을 가진 여러 확장이 등록될 수 있다고 말한다. 다른 항목이 이미 같은 기능 영역을 차지하고 있다는 이유만으로 유효한 요청이 실패해서는 안 된다. 또한 최소 한 쌍의 레지스트리/레지스트라 또는 서버/클라이언트가 확장을 구현·배포했다면 관용적으로 검토하라고 요구한다.

이는 낮지만 의미 있는 기준이다. 전적으로 추상적인 네임스페이스 주장은 걸러낸다. 시장 선거를 치르지는 않는다.

등재 판단은 의도적으로 협소하다

EPP 레지스트리는 RFC 8126에 기술된 'Specification Required' 정책에 따라 운영된다. 요청에는 영구적이고 공개적으로 접근 가능한 사양이 필요하고, 검토는 지정 전문가가 수행한다. 현재 초안에서 허용되는 참조에는 RFC와 언제든 쉽게 열람 가능한 사적 사양이 포함되며, 영어판이 존재해야 한다. 일반 Internet-Draft는 향후 등록을 위한 내구성 있는 참조가 아니며, RFC 7120의 조기 할당 경로도 이 절차를 대신하지 않는다.

이 조건들은 공개 네임스페이스가 문서화되지 않은 문자열의 집합이 되는 것을 막는다. 미래의 구현자가 식별자가 원래 무엇을 뜻하려 했는지 찾아낼 수 있게 한다. 또한 제출에 대해 답할 사람이나 조직을 만든다. 실제 레지스트리는 이름, 문서 상태, 참조, 등록자, 적용 TLD, 지식재산권 정보, 활성·비활성 여부, 주석을 기록한다.

전문가의 검토에는 실질이 있다. 초안은 건축적 건전성, 충분한 개인정보 문서화, 합리적인 URI 구성, IETF 또는 비-IETF XML 네임스페이스의 올바른 사용을 요구한다. 통상 주 전문가가 요청을 처리한다. 부재 시에는 백업 풀이 단순 다수결 합의로 결정한다. 이해충돌을 인지한 전문가는 회피해야 하고, 어려운 질문은 REGEXT 메일링 리스트에 노출될 수 있다.

그러나 이 가운데 어느 것도 검토를 비교 조달로 바꾸지 않는다. 전문가에게 기존 확장이 새 확장보다 우아한지, 상업적으로 성공했는지, 정치적으로 정당한지 판단하라는 지시는 없다. 과업은 제안된 항목이 문서화되어 있고, 레지스트리에 넣기에 기술적으로 충분히 응집되어 있으며, 실제 구현에 근거하는지 판단하는 것이다. 등록은 네임스페이스의 모호성을 막는다. 기능에 대한 배타적 권한을 부여하지 않는다.

이 경계가 특히 중요한 이유는 초안 자체가 아직 RFC가 아니기 때문이다. 개정판 10은 2026년 8월 17일에 발행되었다. Datatracker는 이를 IESG에 제출되어 RFC Editor 대기열에서 편집자 배정을 기다리는, Best Current Practice가 될 의도의 활성 Internet-Draft로 표시한다. 승인·공개되면 RFC 7451을 대체할 것이다. 공개 전까지는 지위와 본문이 달라질 수 있다.

한 쌍의 배포는 존재를 증명할 뿐, 도달 범위를 증명하지 않는다

레지스트리의 관용 지시는 실용적 단위에 기초한다. 최소 한 쌍의 레지스트리/레지스트라, 더 일반적으로는 한 쌍의 서버/클라이언트가 확장을 구현·배포했다는 것. 이 단위가 중요한 이유는 EPP가 쌍방향 운영 프로토콜이기 때문이다. 서버만 내보내거나 클라이언트만 이해하는 확장은 의도된 교환을 완성할 수 없다. 작동하는 한 쌍은 설계 문서만큼의 증거를 넘어선다.

그러나 주장을 증거의 도달 범위를 넘어 쉽게 늘일 수 있다. 한 쌍은 해당 레지스트리를 서비스하는 모든 레지스트라가 확장을 지원함을 보이지 않는다. 한 레지스트라가 모든 레지스트리 연결에서 같은 버전을 구현함을 보이지 않는다. 항목에 나열된 모든 TLD에 대한 지원, 또는 선택 필드가 서로 다른 소프트웨어 스택에서 동일하게 동작함을 보이지 않는다. 이 기준이 말하는 것은 메커니즘이 사양에서 최소 한 건의 실제 대화로 넘어왔다는 사실이다.

'Active'도 같은 규율로 읽어야 한다. 레지스트리는 구현되어 사용 중인 확장을 활성으로 정의한다. 비활성은 구현·사용되지 않았거나, 사양이 더 이상 열람 불가능한 것이다. 이는 채택률이 아니라 수명 주기 신호다. 한 행은 거래량, 실패율, 지리적 도달, 소프트웨어 커버리지, 운영 의존성을 보고하지 않는다. 그런 측정값이 없다고 해서 만연체 가정으로 채워서는 안 된다.

TLD 필드는 범위를 좁히는 데 도움이 되지만 그것조차 호환성 매트릭스가 아니다. 확장과 연관된 존 목록은 어떤 클라이언트 버전이 이를 지원하는지, 사용이 필수인지 선택인지, 게이트웨이가 변환하는지, 같은 의미론이 모든 존에 적용되는지 말하지 않는다. 등록은 좌표를 제공한다. 도달 범위는 배포 증거가 제공한다.

레지스트리에는 이미 병렬 답이 들어 있다

2026년 9월 4일에 갱신된 운영 중인 IANA EPP 확장 레지스트리는 공존이 이론이 아님을 이례적으로 분명하게 보여준다. 여기에는 Standards Track 문서와 '기타(Other)' 문서, 활성·비활성 항목이 모두 들어 있다. 더 중요한 것은 주석이 직접 겹치는 확장 쌍을 식별한다는 점이다.

국제화 도메인 이름의 경우 CORE에 연관된 항목은 해당 TANGO 확장과 구문·기능 면에서 동일하되 다른 XML 네임스페이스를 사용한다고 기술한다. 레지스트리는 CORE와 TANGO의 개인정보 보호 확장에 대해서도 같은 종류의 알림을 제공한다. 기능은 맞물린다. 네임스페이스는 맞물리지 않는다.

운영자는 그 관찰을 '이 둘은 하나의 프로토콜'로 안전하게 줄일 수 없다. XML 네임스페이스는 전송상 정체성의 일부다. 한 네임스페이스로 요소를 보내도록 준비된 클라이언트는, 스키마와 의도된 연산이 비슷하더라도 자동으로 다른 쪽을 말하지 않는다. 서버는 둘 중 하나, 둘 다, 혹은 둘 다를 지원하지 않을 수 있다. 정책, 배포 시점, 테스트 스위트, 변경 관리 체계는 주석이 작성된 시점 이후에 갈라질 수 있다.

또한 두 행을 경쟁이 실패했다는 증거로 읽어서도 안 된다. 병렬 네임스페이스는 역사적 순서, 분리된 커뮤니티, 라이선스나 거버넌스 선택, 서로 다른 배포 관계, 혹은 구현 전 조정 비용을 반영할 수 있다. 레지스트리의 역할은 그 사실들이 계속 찾을 수 있도록 두는 것이다. 개념적 단정함을 만들려고 한 행을 삭제하면 옛 트래픽과 설치된 코드를 해석하기가 오히려 어려워진다.

올바른 질문은 '어느 행이 존재할 자격이 있는가'가 아니다. '각 행이 정확히 어떤 주장을 뒷받침할 수 있는가'이다. 참조는 네임스페이스에 붙은 사양을 확립할 수 있다. 등록자 필드는 기록을 요청한 주체를 확립할 수 있다. 상태는 레지스트리의 현재 수명 주기 분류를 보여줄 수 있다. 주석은 알려진 중첩을 표시할 수 있다. 그러나 어느 필드 하나만으로도 특정 프로비저닝 시스템에서의 대체 가능성이 입증되지 않는다.

공존 지도가 층위를 분리한다

운영자에게는 레지스트리 행의 단순 내보내기가 아니라, 결정을 위해 만들어진 시각이 필요하다. 나는 이를 공존 지도라고 부를 것이다. 제안된 IANA 필드 세트도 아니고 IETF 초안의 언어도 아니다. 레지스트리 데이터, 사양, 운영 증거로 조립한 분석 층위다.

첫 열은 기능 계열이어야 한다. IDN 관리, 개인정보 보호, 런치 운영, 요금 정보, 연락처 처리, 또는 다른 내구성 있는 역량. 이렇게 하면 등가 선언 없이 겹치는 항목을 함께 볼 수 있다.

둘째는 전송상 정체성을 보존해야 한다. XML 네임스페이스, 해당하는 경우 스키마 위치, 명령·응답 접점, 사양 버전. 네임스페이스 차이가 공유 기능 레이블 뒤로 사라져서는 안 된다.

셋째는 등록 계보를 담아야 한다. 영구 참조, 문서 상태, 등록자, 전문가 조치 날짜, 검토 경로. 논쟁된 요청에 메일링 리스트 논의나 백업 패널 결정이 필요했다면, 그 기관적 맥락은 항목과 함께 있어야 한다.

넷째는 명시적 범위를 가진 배포 증거를 기술해야 한다. 어느 레지스트리/서버 및 레지스트라/클라이언트 쌍이 사용을 입증했는가? 어느 날짜, 버전, TLD에서? 양측이 증거를 제공했는가, 문서에서 추론했는가, 적합성 테스트에서 관찰했는가? '최소 한 쌍'은 정확히 그대로 기록해야 하며, '업계 배포'로 격상되지 않아야 한다.

다섯째는 중첩 주장을 식별해야 한다. 유사성이 등록자에 의해 주장되었는가, IANA 주석에 기술되었는가, 스키마 비교로 입증되었는가, 거래에서 관찰되었는가? '기능적으로 동일'이 모든 연산, 오류 경로, 선택 필드를 커버하는가, 아니면 문서화된 핵심만을 커버하는가? 주장은 보편적이지 않으면서도 강할 수 있다.

여섯째는 현재 클라이언트/서버 지원과 변환 동작을 보여야 한다. 게이트웨이가 한 네임스페이스를 다른 쪽으로 매핑한다면, 지도는 매핑의 소유자와 무엇이 소실될 수 있는지를 밝혀야 한다. 변환이 존재하지 않는다면, 그 부정적 사실 자체가 운영상 가치를 지닌다.

일곱째는 수명 주기 역사를 보존해야 한다. 초안은 수정, 비활성화, 삭제를 구분하지만, 레지스트리에 역사 메커니즘이 없고 삭제된 항목은 그 뒤로 거슬러 추적할 수 없다는 것도 인정한다. 따라서 공존 지도에는 날짜가 찍힌 스냅샷이나 다른 내구성 있는 기록이 필요하다. 그렇지 않으면 퇴역이 옛 로그, 계약, 실패한 거래를 이해하는 데 필요한 증거를 파괴할 수 있다.

이 열들이 모이면 네 주장이 하나로 뭉개지는 것을 막는다. 어떤 확장이 등재되어 있다. 어딘가에 배포되어 있다. 여기서 지원된다. 다른 확장과 호환된다. 각각은 참이면서 다음 항목은 거짓일 수 있다.

수정과 삭제는 증거 면을 바꾼다

새 초안은 등재만을 명확히 하지 않는다. 항목 삽입, 수정, 비활성화, 삭제 절차를 기술한다. 상태 변경에는 근거가 필요하다. IETF 합의 항목의 삭제에는 IESG 승인이 필요하다. 비-IETF 항목은 IESG 또는 지정 전문가와 협력하는 원 등록자에 의해 삭제·비활성화될 수 있다.

이 통제들은 표가 운영 의존성임을 인정한다. 그러나 고유 역사의 부재는 비대칭 리스크를 만든다. 경쟁 확장을 추가하면 보이는 기록이 늘어난다. 하나를 삭제하면, 특히 사양도 열람 불가능해질 경우, 이전 의존성이 이해하기 어려워질 수 있다. 즉시의 표는 더 깔끔해지는 동시에 과거를 재구성하는 능력은 나빠질 수 있다.

그래서 비활성 상태와 삭제는 서로 바꿔 쓸 수 없다. 비활성화는 새 용도로 선택해서는 안 되는 구현을 위한 좌표를 유지한다. 삭제는 좌표를 현재 레지스트리에서 빼낸다. 옛 거래, 소프트웨어, 계약이 여전히 그 네임스페이스를 참조할 수 있다면, 활성 사용이 끝났더라도 보존이 기본 증거적 본능이어야 한다.

같은 원리가 수정에도 적용된다. 참조, TLD 목록, 주석을 갱신하면 현재 행은 좋아지지만, 오래된 교환을 조사하는 운영자는 그 당시 레지스트리가 무엇이라고 했는지 알아야 한다. 현 상태 카탈로그는 현재 구현을 조율할 수 있다. 스냅샷 없이는 과거 분쟁을 정리할 수 없다.

표준 지위는 별개의 축이다

IANA 표는 구현자가 마주치는 모든 것을 네임스페이스가 커버해야 하기 때문에 서로 다른 종류의 문서를 하나의 운영 카탈로그에 놓는다. 이 공존은 유용하지만 또 하나의 허위 위계를 부른다. IANA 레지스트리의 한 행이 그 밑의 문서 상태가 사라질 만큼 공식적으로 보일 수 있다.

RFC 2026은 인터넷 표준 절차에서 단계와 스트림을 구분한다. RFC 7451은 등록 프레임워크를 만들었고, RFC 8126은 등록 정책을 정의하며, RFC 5730은 EPP의 기본 프로토콜을 정의하고, RFC 3735는 EPP의 확장 방법을 설명한다. Specification Required로 수용된 사적 사양은 IANA가 그 옆에 기록했다고 해서 Standards Track RFC가 되지 않는다. 반대로 Standards Track이 아닌 확장도 중요한 운영 의존성일 수 있다.

따라서 공존 지도는 표준 지위를 배포의 대리 지표로 쓰지 않으면서 표준 지위를 보여야 한다. 'Standards Track'과 '널리 사용됨'은 서로 다른 질문에 답한다. '기타'와 '불신뢰'도 그렇다. 기관적 정당성, 기술적 사양, 설치된 도달 범위가 별개의 축으로 보일 때 거버넌스는 명확해진다.

출처