요약

  • 현재 REGEXT 초안은 확장의 등록 연락처 또는 IESG가 임의 항목에 대해 IANA RDAP Extensions 레지스트리에서 날짜가 지정된 폐기(deprecation)를 요청할 수 있도록 허용한다. 이는 레지스트리 기록을 바꾸는 것이지, 서버나 클라이언트의 코드를 원격으로 제거하는 것이 아니다.
  • 함께 진행 중인 버전 관리 초안은 서버가/help에서start,end, 기본값, 선행·후속 버전 신호를 제공하고, 각 응답에 사용된 버전을 식별하며, 클라이언트가 버전을 요청할 수 있게 한다. 이 신호들은 전환을 조율할 수 있지만 미지의 클라이언트 군을 열거하지는 못한다.
  • 운영자에게 필요한 것은 승인된 레지스트리 행위, 각 서버의 광고·관찰 상태, 표본화된 클라이언트 수요, 남는 불확실성을 구분하는 은퇴 영수증이다. 이는 Daniel Kade의 거버넌스 제안이며 IETF 요구사항이 아니다.

가장 깔끔한 소프트웨어 은퇴는 한 셀 안에 들어가는 것처럼 보인다. 오래된 이름 옆에 날짜를 붙이고, 대체물을 공표하고, 적당한 기간이 지나면 호환 경로를 삭제하는 것이다. 레지스트리는 첫 번째 행위를 잘 해낸다. 공개 어휘를 보존하고, 기록 상태를 바꿀 권한을 가진 주체를 식별한다. 분산 프로토콜은 마지막 행위에서 훨씬 못하다. 클라이언트는 공개 RDAP 서버에 질문하기 전에 등록할 필요가 없고, 서버는 누가 그 클라이언트를 유지보수하는지, 특정 응답 형태에 얼마나 급하게 의존하는지 영영 알지 못할 수 있다.

이 간극은 IETF 등록 프로토콜 확장(Registration Protocols Extensions) 워킹 그룹의 활성 문서 두 편에서 특히 선명하다. 2026년 8월 13일자RDAP Extensions개정판 15는 IANA RDAP Extensions 레지스트리에Deprecation Date(폐기 예정일) 필드를 제안한다. 7월 31일자Versioning in the Registration Data Access Protocol개정판 07은 지원 버전, 기본값, 대체 버전, 종료 시점을 공표하기 위한 프로토콜 장치를 제안한다. 두 문서를 합치면 그럴듯한 마이그레이션 시나리오가 된다. 동시에 레지스트리 날짜, 서버 기한, 클라이언트 준비 상태가 동일한 사실이 아님을 보여준다.

두 문서 모두 아직 Internet-Draft다. Datatracker는 이들을 표준 트랙(Standards Track)을 목표로 하는 REGEXT 워킹 그룹 문서로 기록하고 있으며, RFC도 배포 의무도 아니다. 개정판 15는 "Revised I-D Needed — Issue raised by WG" 상태에 있으며 담당 Area Director가 없다. 이 문서들의 세부 사항이 가치 있는 이유는 바로 현재 절차가 부여하는 이상의 권한을 누구에게도 주지 않으면서 해결되지 않은 거버넌스 문제를 드러내기 때문이다.

레지스트리는 이름의 공개 상태를 관리한다

RDAP은rdapConformance와 이름, 경로, 매개변수 등 다른 프로토콜 요소에 실린 식별자를 통해 기본 쿼리와 응답 형식을 확장한다. 이 식별자들은 충돌을 방지하고 구현자를 사양으로 안내한다. 불투명하다. 버전 번호처럼 보이는 접미사가 그 자체로 어떤 식별자가 다른 식별자를 대체한다는 증명이 되지는 않는다. 운영자는 정의 문서를 확인해야 한다.

개정판 15는 각 레지스트리 행에 전체 날짜(full-date) 형식의 폐기 필드를 부여한다. 레지스트리에 기재된 연락처는 자신의 확장에 대한 폐기를 IANA에 요청할 수 있다. IESG는 임의의 RDAP 확장에 대해 IANA에 폐기를 요청할 수 있다. 따라서 이 제안은 권한의 두 가지 가능한 원천과 결과 기록의 한 관리자를 지명한다. 그러나 구식 확장의 어떤 사용자도 배포 통제권을 이들 주체에게 이전했다고 말하지는 않는다.

이 초안은 또한 IANA에 이미 구식(obsolete)으로 표시된 두 ICANN 식별자, 즉icann_rdap_response_profile_0과icann_rdap_technical_implementation_guide_0에 2025년 8월 21일자 날짜를 붙이도록 요청한다. 이 글의 조사 기준 시점에 라이브 레지스트리(2026년 9월 1일 마지막 업데이트)는 두 식별자를 버전 1 후속 항목과 함께OBSOLETED로 표시하고 있으나, 아직 별도의 날짜 열은 표시하지 않는다. 이는 IANA의 실패를 의미하는 증거가 아니다. 새 필드는 아직 RFC가 되지 못한 작업 문서가 제안한 것이다.

이 구분은 절차적 예의 이상으로 중요하다. "폐기(obsolete)"는 레지스트리 질문, 즉 지금 이 식별자를 어떻게 이해해야 하는가에 답한다. 배포 질문, 즉 어떤 서버가 여전히 이를 출력하는가에는 답하지 않는다. 의존성 질문, 즉 어떤 클라이언트가 여전히 이를 파싱하고, 그에 연관된 동작을 요구하고, 그것이 사라지면 실패하는가에도 답하지 않는다. 공개 레지스트리는 첫 번째 답에 권위를 부여하면서 나머지 두 질문을 모른다는 사실을 완전히 정직하게 유지할 수 있다.

등록 규칙은 레지스트리의 한정된 역할을 강화한다. 현재 정책은 Specification Required에 Expert Review를 결합한 것이다. 개정판 15는 최소 세 명, 이상적으로 네 명 또는 다섯 명의 검토자를 요구하고, 배정된 등록을 제2의 전문가가 재확인하도록 요구한다. 사양은 안정적이고, 쉽게 이용 가능하며, 독립 구현이 상호운용할 만큼 충분히 상세해야 한다. 이는 공유 어휘에 대한 강력한 진입 통제이지 배포된 소프트웨어의 재고 목록이 아니다.

서버는 자신이 서비스할 것을 통제한다

버전 관리 초안은 다른 계층에서 작동한다. 제안된versioning_help멤버는 서버가 지원하는 확장과 버전을 서술하고, 기본값을 식별하고, 문서를 가리키고, 선행 버전을 후속 버전과 연결하고,start와end시점을 공표하도록 한다.versioning_data멤버는 특정 응답을 형성한 확장 버전을 기록한다. 클라이언트는versioning_list미디어 타입 매개변수로 원하는 버전을 표현할 수 있다.

이는 차별화되지 않은 서비스 종료 통지가 하나의 기록을 제공하던 것을 세 개의 기록으로 만든다./help는 서버의 지원 정책을 서술한다.versioning_data는 반환된 표현을 서술한다. 클라이언트의 요청은 그 교환에 대한 선호를 서술한다. 어느 것도 다른 것으로 몰래 대체되어서는 안 된다. 서버는 기본값으로 사용하지 않으면서 구식 버전을 지원할 수 있다. 구식 버전이 계속 제공되는 가운데 클라이언트가 요청했기 때문에 응답이 새 버전을 사용할 수 있다. 클라이언트는 선호를 생략하고 기본값을 받을 수 있으며, 이는 모든 대안을 이해한다는 증명이 아니다.

제안된end멤버는 특히 과잉 해석하기 쉽다. 이는 확장-버전 객체가 지원을 중단하게 될 날짜와 시각이다. 그 시각이 지나면 해당 객체는 광고 집합에서 제거되어야 한다.end가 없으면 지원 만료 계획이 없다는 뜻이다. 이는 서버가 선언한 동작에 대한 정확한 서술이지, 모든 하류 클라이언트가 마이그레이션을 완료했다는 인증서가 아니다.

개정판 07은 비호환 변경을 위한 중간 단계를 권고한다. 서버는 폐기 요소와 대체 요소를 함께 노출하고,/help에서 전환을 광고하고, 기간 동안 구형 클라이언트의 계속 사용을 허용하며, 이후 폐기 형태를 제거한다. 두 번째 패턴은 버전을 겹쳐 배치하고, 기본값을 옮기고, 종료 시점까지 클라이언트가 구버전을 선택할 수 있게 한다. 이는 갑작스러운 파손을 줄이기 위한 합리적 장치다.

그러나 얼마나 많은 버전을 얼마나 오래 겹치게 지원할지는 서버가 선택한다. 클라이언트가 등록되어 있지 않다면 "충분한 시간"을 달력만으로 도출할 수 없다. 90일의 겹침은 중앙 관리되는 플릿에게 관대할 수 있지만, 연간 보고 때만 쓰이는 보관된 스크립트에는 무모할 수 있다. 프로토콜은 문과 닫히는 시각을 노출할 수 있다. 그러나 그 문을 쓸 수 있는 모든 사람이 통지를 읽었다는 것은 증명하지 못한다.

미지의 클라이언트는 사실이지 영구 거부권이 아니다

개정판 15는 이 어려운 한계를 직접 진술한다. RDAP 클라이언트와 RDAP 서버 사이에는 파괴적 변경이 모든 클라이언트에 영향을 미치지 않음을 누구든 절대적으로 판정할 수 있게 해주는 관계가 존재하지 않는다. 공개 쿼리 인터페이스가 가치 있는 부분적 이유는 양자 간 계약을 요구하지 않기 때문이다. 바로 그 개방성이 운영자가 완전한 마이그레이션 점호를 수행하는 능력을 약화시킨다.

이것이 구형 인터페이스가 영원히 제거될 수 없다는 뜻은 아니다. 불확실성을 영구 거부권으로 바꾸면 또 다른 거버넌스 실패가 생긴다. 호환 코드가 쌓이고, 모순적 의미 체계가 살아남고, 보안·프라이버시 개선이 정체를 드러내지 않는 가상의 사용자들 때문에 지연될 수 있다. 올바른 대응은 확실성이 아니라 한정된 증거다.

요청 텔레메트리는 특정 서버가 어떤 구간 동안 구버전 수요를 받았음을 보여줄 수 있다. 그 신호가 합법적으로 존재하는 곳에서는 클라이언트 소프트웨어 서명, 네트워크 또는 인증된 계정별로 집중 지점을 식별할 수 있다. 기본값이 바뀐 뒤 수요가 떨어졌음을 보여줄 수도 있다. 그러나 공개 RDAP 요청에는 등록 대상과 네트워크 식별자가 담길 수 있다. 준비 상태를 증명하기 위해 무기한, 연결 가능한 클라이언트 이력을 수집하는 마이그레이션 프로그램은 인터페이스 문제를 풀기 위해 프라이버시 문제를 만든다.

따라서 부재(absence)는 신중하게 표현되어야 한다. "이 표본화 정책 하에서 이 측정 구간 동안 이 서버들에서 구버전 요청이 관찰되지 않았다"는 방어 가능하다. "구버전에 의존하는 클라이언트가 없다"는 그렇지 않다. 마찬가지로, 성공한 신버전 응답 하나는 한 시점에 한 경로가 작동했다는 것만 증명한다. 리퍼럴, 리다이렉트, 캐시, 라이브러리, 주기적 워크플로우가 수렴했다는 증명은 아니다.

세 권한을 위한 은퇴 영수증

유용한 은퇴 영수증은 정확한 확장 식별자, 그리고 정의되어 있다면 정확한 버전으로 시작해야 한다. 레지스트리 행위가 기재된 연락처에 의한 요청인지 IESG에 의한 것인지, IANA가 수용한 날짜, 표시되는 레지스트리 상태를 기록해야 한다. 그것이 권한 영수증이다. 서버 배포 기록이라고 주장해서는 안 된다.

두 번째 항목은 호환성 계약을 서술한다. 선행 버전은 무엇인가? 후속 버전은 무엇인가? 변경은 구문상인지, 의미상인지, 정책에 의한 것인지, 혼합인지? 어떤 필드, 경로, 매개변수가 사라지는가? 구형 표현과 신형 표현이 모호함 없이 공존할 수 있는가? 안정적인 사양은 어디에 있는가? 벗겨진 숫자 접미사만으로는 부족하다.

세 번째 항목은 서버별 또는 운영 코호트별이다. 날짜가 찍힌/help관찰, 기본값 변경, 공표된start와end시점, 대표적인versioning_data, 미지원 요청에 대한 오류 동작, 롤백 규칙을 보존해야 한다. 계획된 제거와 관찰된 제거는 별도 필드여야 한다. 자신의 종료일을 놓친 서버는 사후에 계획을 다시 쓰는 대신 드리프트를 드러내야 한다.

네 번째 항목은 세계를 식별한다고 가장하지 않은 채 수요를 요약한다. 측정 창, 대상 서버, 제외 항목, 프라이버시 집계, 구버전 요청 수 또는 비율, 접촉한 알려진 관리형 클라이언트, 미해결 고영향 클라이언트, 사용된 판정 규칙을 진술해야 한다. 클라이언트 신호가 존재하지 않으면 영수증이 그렇게 말해야 한다. 텔레메트리를 이용할 수 없다면 조작된 0보다 "알 수 없음"이 낫다.

마지막으로, 영수증은 제거 결정, 결정자, 증거 기준 시점, 예외, 제거 후 관찰을 기록한다. 인시던트나 롤백에 연결하되, 그 부재를 보편적 성공의 증명으로 취급하지 않는다. IANA 항목이 먼저 바뀌더라도, 한 운영자가 더 오래 호환성을 유지하더라도, 대체 문서 자체가 개정되더라도 기록은 해석 가능해야 한다.

이 구조는 간단한 권력 배분을 반영한다. 레지스트리 권한은 이름의 공개 상태를 통제한다. 서버 운영자는 자신이 서비스하는 인터페이스를 통제한다. 클라이언트 운영자는 자신이 업그레이드하는 소프트웨어를 통제한다. 조율은 이들의 행위를 연결할 수 있지만 관장(권한)을 합칠 수는 없다.

출처