요약

  • IETF의 EPP-over-HTTPS 초안 개정 04판은 HTTP 결과와 권위 있는 EPP 결과 사이에 명확한 선을 긋습니다. HTTP 200은 EPP 성공과 EPP 실패 어느 쪽이든 담을 수 있으며, 유효한 EPP 응답이 없다면 처리 단계에 도달했을 수 있는 명령의 결과는 불확정입니다.
  • 재시도는 인프라의 기본값이 아닙니다. EoH 클라이언트가 확장을 포함한 전체 EPP 명령이 멱등적 의미를 가지며 명령 순서를 보존한다는 것을 알고 있을 때에만 허용되는 애플리케이션 판단입니다.
  • 따라서 레지스트리와 레지스트라는 무엇이 알려졌는지, 무엇이 알려지지 않았는지, 누가 재시도를 하거나 포기했는지, 최종 객체 상태가 어떻게 정합되었는지를 기록하는 명령 처분 수취증이 필요합니다.

일반적인 웹 대시보드에서 초록색200 OK는 안심의 신호입니다. 요청이 응답할 의향이 있는 무언가에 도달했고, 그 답은 성공 계열에 속합니다. 이 시각적 문법은 워낙 익숙해서 별도의 한정 없이 모니터링 시스템, 장애 티켓, 경영 보고서로 그대로 흘러 들어가곤 합니다. 초록은 "완료"가 됩니다.

하지만 HTTPS로 전달되는 레지스트리 프로비저닝 명령에서 이 지름길은 틀렸습니다. 2026년 9월 3일에 공개된draft-ietf-regext-epp-https-04는 이 구분을 이례적으로 명확하게 만듭니다. 요청이 확장 가능 프로비저닝 프로토콜(EPP) 처리 계층에 도달해 서버가 EPP 응답을 생성했다면, 내부 EPP 결과가 성공을 말하든 실패를 말하든 바깥 HTTP 응답은 200이어야 합니다. 유효한 EPP 응답이 없고 그럼에도 요청이 처리 단계에 도달했을 가능성이 있다면, 명령의 결과는 실패가 아니라 불확정입니다.

이것은 작은 전송 규칙이지만 큰 거버넌스 결과를 낳습니다. 레지스트라는 레지스트리에 객체 생성, 갱신, 이전, 업데이트 또는 삭제를 요청했을 수 있습니다. HTTP 교환은 전달과 웹 대면 서비스에 관한 정보를 줄 수 있습니다. 매핑이 상정하는 권위 있는 애플리케이션 결과는 오직 EPP 응답만 줄 수 있습니다. 그 응답이 없을 때 조직이 갖는 것은 부정적 답이 아니라, 자동화가 불확실성을 또 다른 변경으로 바꾸도록 놔두면 더 위험해질 수 있는 미해결 상태입니다.

두 상태 체계가 하나의 봉투를 공유한다

EPP는 공유 중앙 저장소에 보관된 객체를 프로비저닝하기 위한 상태 유지형 순차 명령-응답 프로토콜로 설계되었습니다. RFC 5730은 그 역할을 세션 관리, 읽기 전용 질의, 객체 변환으로 나눕니다. 명령은 원자적이며 멱등적으로 만들 수 있도록 설계되었다고 규정하고, 모든 전송 매핑이 순서와 상태를 보존하고 파이프라이닝 허용 여부를 명시해야 한다고 요구합니다.

HTTPS 초안은 이 프로토콜을 POST 요청 위에 매핑합니다. 초기 빈 POST는 HTTP 200이 EPP 인사말을 돌려주고 쿠키 기반 HTTP 세션을 수립할 때에만 EPP-over-HTTPS 연결을 엽니다. EPP 로그인이 성공하면 인증된 EPP 세션이 생성됩니다. 이후 각 POST는 하나의 EPP 명령을 담고, 처리된 각 명령은 하나의 EPP 응답을 낳습니다.

이 매핑은 의도적으로 터널입니다. 저자들은 운영자가 웹 인프라와 기존 EPP 소프트웨어의 상당 부분을 재사용하기를 바라지만, HTTP 계층이 레지스트리 의미론에 대한 지식을 얻는다고 주장하지는 않습니다. 실제로 초안은 리버스 프록시와 클라우드 플랫폼이 보통 내세우는 여러 기능을 제한합니다: 캐싱, 멀티플렉싱, 인프라 인증, 로깅, 자동 재시도는 이것이 평범한 무상태 웹 API인 것처럼 그대로 물려받을 수 없습니다.

핵심 규칙이 여기에 따릅니다. HTTP 상태 코드는 EPP 명령의 결과를 전달해서는 안 됩니다. 200은 EPP 처리 경로가 EPP 응답을 산출했다는 뜻이며, 그 안의 XML은 성공이든 실패든 보고할 수 있습니다. 반대로 게이트웨이 타임아웃, 과부하 응답, 미지원 미디어 타입 응답은 HTTP 계층의 결과이지 EPP 응답이 아닙니다. 응답이 유실되기 전에 요청이 애플리케이션 경계를 넘었을 가능성이 있다면, 바깥 실패가 내부 명령이 거부되었다는 증거가 되지 않습니다.

유효하지 않은 세션조차 이 분리를 보여줍니다. 요청이 비어 있거나 유효하지 않은 세션 식별자와 함께 EPP 처리에 도달하면, 초안은 HTTP 200 안에 EPP2002명령 사용 오류를 요구합니다. 공유되는 숫자200은 서로 다른 두 코드 공간의 우연입니다. 봉투를 판정으로 취급하면 실제로 중요한 유일한 결과를 버리는 셈입니다.

불확정은 실제 운영 상태다

운영자들은 불확실한 결과를 가장 가까운 이분법으로 압축하는 경향이 있습니다. 타임아웃된 쓰기는 실패로 표기되고, "이미 존재함" 응답을 돌려준 재시도는 성공으로 표기되며, 이후의 객체 질의는 어느 요청이 상태를 만들었는지에 대한 증명으로 취급됩니다. 각 압축은 편할 수 있지만, 어느 것도 증거 사슬을 보존하지 않습니다.

불확정은 대신 일급 처분 상태로 표현되어야 합니다. 그것은 세 가지를 동시에 의미합니다: 유효한 권위 있는 EPP 응답을 손에 쥐고 있지 않다; 증거는 애플리케이션 처리 가능성을 배제하지 않는다; 새 명령은 불확실성을 증폭시킬 수 있다. 이 상태는 서버에 대한 비난이 아닙니다. 네트워크는 응답을 잃고, 중개자는 고장 나고, 세션은 만료되고, 구현은 서로 다릅니다. 중복 변경이 일어날 것이라는 예측도 아닙니다. 가용 증거가 뒷받침하는 가장 정밀한 진술일 뿐입니다.

이 정밀함이 중요한 이유는 레지스트리 명령이 서로 교환 가능한 메시지가 아니기 때문입니다. 질의와 갱신은 서로 다른 노출을 만듭니다. 기본 프로토콜은 명령이 멱등적으로 만들 수 있도록 설계되었다고 말하지만, HTTPS 초안은 모든 구현의 모든 명령에 무조건적인 재시도 허가를 부여하지 않습니다. 전체 명령에는 확장이 포함되며, 확장은 애플리케이션 의미론을 바꿀 수 있습니다. 기본 동사만 검사한 운영자는 실제로 전송된 요청을 검사하지 않은 것입니다.

재시도 판단권은 미들박스가 아니라 클라이언트에 있다

HTTP 의미론은 보수적인 출발점을 제공합니다. RFC 9110은 POST를 멱등적이라고 정의하지 않습니다. 클라이언트는 요청 의미가 실제로 멱등적임을 알거나 첫 요청이 적용되지 않았음을 확인할 수 없는 한 비멱등 메서드를 자동으로 재시도하지 말 것을 권고합니다. 프록시는 비멱등 요청을 자동으로 재시도해서는 안 됩니다.

개정 04판은 이 규율을 EPP로 가져옵니다. EoH 클라이언트는 실패가 일시적일 가능성이 있고, HTTP 상태 의미가 이를 허용하며, 클라이언트가 확장 전부를 포함한 EPP 명령이 멱등적 애플리케이션 의미를 가진다는 것을 알고 있을 때에만 재시도할 수 있습니다. 재시도에는 동일한 명령과, 존재했다면 동일한 클라이언트 트랜잭션 식별자가 담겨야 합니다. 유효한 응답이 도착하거나 세션이 포기될 때까지 어떤 후속 EPP 명령도 전송될 수 없습니다. 운영자는 자신이 통제하는 중개자가 EPP POST를 자동으로 재시도하지 않도록 구성해야 합니다.

이 권한 배분에는 이유가 있습니다. 로드 밸런서는 연결, 상태 코드, 타임아웃을 관찰할 수 있습니다. 그러나 레지스트리 확장이 명목상 반복 가능한 작업을 서로 다른 효과를 가진 요청으로 바꾸는지는 일반적으로 판단할 수 없습니다. EPP 명령 시퀀스도 그것이 소유하지 않습니다. 중개자에게 재시도를 허용하면 인프라 구성 요소가 애플리케이션 정책의 숨은 저자가 됩니다.

같은 주의가 트랜잭션 식별자에도 적용됩니다. RFC 5730은 클라이언트가 제공한clTRID를 허용하고 응답에 서버가 할당한 고유svTRID를 요구합니다. 둘은 함께 명령-응답 동기화 무결성을 제공하며, RFC는 양측이 이를 기록, 보관, 보호할 것을 권고합니다. HTTPS 초안은 허용된 재시도에 동일한clTRID를 요구합니다. 그러나 상관관계는 자동으로 중복 제거가 아닙니다. 어느 문서도clTRID반복만으로 모든 서버가 두 번째 실행을 억제하도록 강제한다고 말하지 않습니다. 운영자가 이 속성에 의존한다면, 명시적인 구현이나 서비스 계약과 그 속성이 실제 작동했다는 증거가 필요합니다.

순서는 증거의 일부다

HTTP/2와 HTTP/3는 동시 스트림을 자연스럽게 만듭니다. EPP는 그 자유를 물려받지 않습니다. 초안은 EPP 세션당 하나 이상의 미완료 HTTP 요청을 금지하고 명령 파이프라이닝을 활성화하지 않습니다. 중개자가 그럼에도 동시 요청을 만든다면, 서버는 그것을 실패 처리할지 직렬화할지를 정의해야 합니다.

이것은 성능 제약만이 아닙니다. 순서는 의미를 바꿉니다. 이후의 업데이트는 생성에 의존할 수 있고, 이전 작업은 어느 클라이언트가 객체를 수정할 자격이 있는지 바꿀 수 있으며, 재시도는 다른 무엇도 상태를 진전시키지 않았을 때에만 안전할 수 있습니다. 이전 결과가 미해결인 동안 후속 명령을 보내지 말라는 지침은 따라서 증거적 장벽으로 기능합니다. 여러 가능한 시퀀스가 동일한 최종 상태를 설명하는 퍼즐로 기록이 변하는 것을 막습니다.

세션을 포기하는 것은 명령을 해결하는 것과 같지 않습니다. 시퀀스를 멈추는 안전 조치입니다. 정합에는 여전히 권위 있는 응답, 서버 측 트랜잭션 추적, 적절히 범위가 한정된 객체 질의, 운영자 확인 또는 합의된 다른 메커니즘을 통해 레지스트리가 무엇을 믿는지 확인해야 합니다. 새 세션이 필요할 수 있지만, 새 전송이 미해결 이력을 지우지는 않습니다.

명령 처분 수취증

일반적인 요청 로그는 인프라 중심으로 조직됩니다. URL, 지연 시간, HTTP 상태, 백엔드, 때로 재시도 횟수를 기록합니다. EPP 감사 기록은 종종 XML 트랜잭션 중심으로 조직됩니다. 터널링된 시스템에서 어느 한쪽 시각만으로는 충분하지 않습니다. 두 시각의 결합이 거버넌스 객체입니다.

명령 처분 수취증은 EPP 명령이 클라이언트를 떠날 때마다 생성되어야 합니다. 다음을 기록해야 합니다:

  1. 명령 계열, 영향을 받는 레지스트리 객체, 확장을 포함한 전체 EPP 명령의 해시 또는 정규화 지문;
  2. EPP 세션 식별자, 클라이언트 트랜잭션 식별자, HTTP 시도 식별자;
  3. 클라이언트가 요청을 전송 계층에 맡긴 시각과 비전달이 증명 가능한 마지막 시점;
  4. 응답을 생성한 중개자를 포함한 HTTP 관찰 결과;
  5. 유효한 응답이 도착했다면 EPP 결과 코드와 서버 트랜잭션 식별자;
  6. 색이나 상태 계열만으로 유도하지 않는 3중 처분 — 해결된 성공, 해결된 실패, 불확정;
  7. 확장의 버전과 의미론을 포함해 전체 명령을 멱등적으로 취급한 문서화된 근거;
  8. 처분이 열려 있는 동안 후속 명령이 유입되지 않았음을 보여주는 순서 장벽;
  9. 재시도, 정합 또는 세션 포기를 승인한 지명된 운영자 또는 클라이언트 정책; 그리고
  10. 사례를 닫은 증거, 그 타임스탬프, 신뢰도, 클라이언트와 레지스트리 기록 사이에 남은 불일치.

이것은 하나의 전역 데이터베이스 스키마를 요구하는 것이 아닙니다. Lu Heng의 최소 초기 명세 접근법은 더 작은 공통 의무를 향해 나아갑니다: 레지스트리와 레지스트라가 로컬 저장소와 정합 절차를 선택하도록 두면서, 구분과 식별자만 보존하는 것입니다. 수취증은 서명된 이벤트, 인시던트 객체, 연결된 로그 쌍 또는 양측 지원 시스템의 케이스일 수 있습니다. 중요한 것은 "알 수 없음"이 조용히 "실패"로 격하되거나 HTTP 성공이 레지스트리 성공으로 격상될 수 없다는 점입니다.

Policy Mirror가 제도적 시험대를 제공합니다. 편의 기능이 명령을 재시도할 때 그 권한을 누가 받는가? 중복 변경이 발생하면 손실을 누가 흡수하는가? 누가 증거를 보고 이의를 제기할 수 있는가? 플랫폼 처리량에 이익을 주면서 정합 비용을 레지스트라, 등록자, 지원 팀에 전가하는 기본값은 단순한 전송 설정이 아닙니다. 인프라에 숨은 정책 선택입니다.

개정 04판이 증명하는 것과 그렇지 않은 것

이 초안은 Standards Track을 위한 활성 REGEXT 워킹 그룹 문서입니다. RFC가 아니며, IESG 검토를 완료하지 않았고, 2027년 3월 7일에 만료되기 전에 변경될 수 있습니다. 워킹 그룹의 2026년 9월 제출 마일스톤은 계획이지, 제출이나 승인이 일어났다는 증거가 아닙니다.

구현 섹션은 Verisign SDK와 IIT-CNR/Registro.it 구현을 언급합니다. 초안 자체의 RFC 7942 고지에 따르면, 이 설명은 기여자가 제공한 것이며 IETF가 검증한 것이 아니고, 어떠한 보증도 함축하지 않으며, 목록이 아닙니다. 구현자가 설계를 실제로 다뤄왔다는 유용한 증거일 뿐입니다. 모든 배포된 중개자가 자동 재시도를 비활성화했고, 모든 확장이 올바르게 분류되었고, 모든 운영자가 불확정 명령을 정합할 수 있다는 것을 증명하지 않습니다.

마찬가지로 제안된 IANA 등록은 초안 안의 제안입니다. 초안 문구가 이미 레지스트리 항목을 만들었다는 것처럼 보고해서는 안 됩니다. 거버넌스는 프로토콜 주장만큼 정확하게 상태 주장을 유지하는 것에서 시작합니다.

출처

  1. IETF Internet-Draft — Extensible Provisioning Protocol (EPP) Transport over HTTPS, revision 04
  2. IETF Datatracker — draft-ietf-regext-epp-https
  3. IETF Datatracker — 문서 이력
  4. IETF REGEXT Working Group
  5. RFC 5730 — Extensible Provisioning Protocol
  6. RFC 5731 — EPP 도메인 이름 매핑
  7. RFC 5734 — EPP TCP 전송
  8. RFC 9110 — HTTP 의미론
  9. RFC 7942 — Running Code 인식 개선
  10. IANA — EPP 확장
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. Lu Heng — The Policy Mirror