Summary

  • 2026년 11월 2일의 RPP 핵심 초안 01판은 도메인 같은 공동 데이터베이스 객체의 관리 작업을 HTTP에 대응시킨다. 데이터 객체 초안은 그 객체 모델을 별도로 정의한다. 아직 IETF 작업 문서다.
  • 도메인 이전은 후원 클라이언트를 바꾸는 일이다. RPP는 이를 자체 수명 주기를 가진 절차 객체로 다룬다. 신청자는 POST /domainNames/{name}/processes/transferProcesses를 보내고, 초안의 예시는 201 Created와 절차 URL을 담은 Location을 돌려준다.
  • 신청자는 보류 중인 이전을 취소할 수 있고 현재 후원 등록대행자는 거부하거나 승인할 수 있다. 지속성 있는 메시지 대기열은 비동기 결과를 알릴 수 있으며, 읽기와 명시적 확인은 서로 다른 동작이다.

도메인이 등록대행자 A에서 B로 ‘이동한다’는 말은 한 번의 작업처럼 들린다. IETF의 RPP 핵심 기록에는 여러 결정이 그 사이에 놓여 있다. 신청으로 절차가 만들어지고, 기존 후원자가 판단하며, 나중에 결과가 메시지로 도착할 수 있다. 첫 Created가 가리키는 것은 초안 예시에서 절차 자원이다. 도메인 기록의 후원자가 이미 바뀌었다는 증명은 아니다.

RPP는 EPP를 다른 이름으로 부르는 규격이 아니라 독립 프로토콜로 설계됐다. EPP 백엔드에 잇는 작업은 따로 다룬다. 핵심 초안은 URL, HTTP 방식, 헤더, 상태 코드를 정하고, 데이터 모델과 실제 메시지 표현은 별도 문서가 맡는다. 요청 로그의 성공 코드를 볼 때에는 어떤 대상이 한 걸음 진행됐는지 먼저 확인해야 한다. 도메인 자체인지, 그 도메인을 둘러싼 절차인지가 중요하다.

새로 생긴 것은 이전의 작업표다

16.9.5절은 이전을 후원 클라이언트의 변경으로 정의하고, 별도 절차에 수명 주기를 준다. 새 등록대행자는 도메인 아래의 transferProcesses에 POST한다. 예시 응답에는 201 Created, RPP 결과 코드, /transferProcesses/latest로 끝나는 Location이 들어 있다. 이 경로는 가장 최근 이전 절차를 찾는 길이다. 도메인의 최종 후원자를 읽은 결과와는 다르다.

클라이언트는 GET으로 절차 상태를 조회한다. 보류 중이면 신청자가 DELETE로 취소할 수 있다. 현재 후원자에게는 transferReject와 transferApprove가 있다. 동작별로 권한을 가진 기관이 다르다. 들어오려는 쪽은 신청할 수 있어도 지금 후원하는 쪽의 승인을 대신 만들어 낼 수 없다. 신청, 절차 상태, 승인 또는 거부, 최종 도메인 기록을 연결해야 이전의 전체 경로가 보인다.

URL이 언제나 남는다는 보장도 없다. 서버가 절차 인스턴스를 공개한다면 가장 최근 것을 latest로 접근할 수 있어야 하고, 영구 ID를 추가로 줄 수 있다. 영속적인 절차 자원을 아예 공개하지 않으면 초안은 201 Created 대신 200 OK를 요구한다. 모든 등록부가 장기 보존 URL을 준다고 가정해서는 안 된다. 그래도 거래 식별자와 이용 가능한 상태, 최종 후원자 조회는 하나의 증거 사슬로 남길 수 있다.

알림을 읽어도 대기열에서는 사라지지 않는다

초안은 클라이언트용 비동기 알림을 지속성 있는 메시지 대기열에 둔다. 다른 당사자의 승인이 필요한 이전의 완료가 한 사례다. 클라이언트는 GET으로 메시지를 가져오고 특정 메시지에 DELETE를 보내 확인한다. 가져왔지만 확인하지 않은 알림은 대기열에 남아야 한다. ‘봤다’와 ‘처리했다’는 따로 기록된다. 최초의 이전 신청 응답과 나중의 완료 통지도 서로 다른 증거다.

일반 작업이 부수적으로 절차를 만들었다면 15절은 rel="rpp-process"를 가진 Link 응답 헤더로 이를 알린다. process는 유형을, processId는 서버가 부여한 영구 식별자가 있을 때 그 번호를 나타낸다. latest는 해당 유형의 최신 절차를 뜻한다. 링크는 앞으로 확인할 작업을 가리킬 뿐 결론을 대신하지 않는다.

공식 자료에는 실제 등록부에서 끝난 도메인 이전의 측정 기록이 없다. 통제 가능한 도메인으로 시험할 때에는 POST 응답, 절차 GET 상태, 기존 후원자의 판단, 결과 메시지, 메시지 확인, 마지막 도메인 후원자를 같은 시간순으로 기록해야 한다. 그때에야 고객 화면의 ‘신청됨’을 ‘이전 완료’로 바꿀 시점을 알 수 있다. 절차의 URL이 생겼어도 도메인은 아직 원래 등록대행자에게 있을 수 있다.

RPP 핵심 초안 01판 · Datatracker 기록 · RPP 데이터 객체 · RFC 5730