요약

  • RFC 3981은 IRIS 코어가 그 자체로는 불충분하도록 의도적으로 설계했다. 유용한 질의, 결과 및 주체 클래스는 레지스트리별 스키마가 정의해야 했고, 인증과 세션은 별도의 전송 계층이 담당했다.
  • 범용 클라이언트를 거부한 것은 실패가 아니라 경계였다. 공통 조회 틀은 레지스트리 유형을 넘어설 수 있었지만, 의미 있는 검색, 안전한 서버 정책, 권한 부여 및 사람 친화적인 표시에는 여전히 도메인 지식이 필요했다.

프로토콜은 보통 자신이 무엇을 가능하게 하는지 선언한다.RFC 3981은 자신이 무엇이 되려 하지 않을지도 선언했다. 기본 XML 스키마는 질의 유형 하나와 독립형 결과 유형 두 가지만 정의했고, 레지스트리 구조는 정의하지 않았다. 문서는 그 코어를 “그 자체로는 제한적인 용도”를 지닌다고 표현했다. 이 한계는 미완성된 구석이 아니었다. 서로 닮지 않은 주체, 색인 및 관계를 지닌 레지스트리를 하나의 프레임워크가 섬길 수 있게 하는 장치였다.

상태 기록,정정 기록및Datatracker 이력에 따르면 2005년 1월 문서는 Standards Track에 놓여 있었고, 이후 RFC 4992가 이를 갱신했다. IRIS — 인터넷 레지스트리 정보 서비스(Internet Registry Information Service) — 는 레지스트리 질의와 결과를 위한 XML 클라이언트-서버 프레임워크였다. 단일 전역 데이터베이스를 위한 스키마가 아니었다.

RFC 3981은 책임을 세 계층으로 나누었다. 레지스트리별 계층은 도메인 또는 주소 레지스트리의 질의, 결과 및 주체 클래스를 정의했다. 공통 IRIS 계층은 검색 집합, 결과 집합, 참조 및 레지스트리 유형 명명 구문을 정의했다. 애플리케이션 전송 계층은 인증, 메시지 전송, 연결 및 세션 관리뿐 아니라 자체 URI 형식도 다루었다. 한 계층에서의 합의가 나머지 두 계층에 대한 권위는 아니었다.

각 레지스트리 유형은 자신의 XML 네임스페이스와 스키마도 식별하는 URN을 받았다. 서버는 여러 레지스트리 서비스 인스턴스를 호스팅할 수 있었다. 그러나 코어는 특정 레지스트리, 레지스트리 식별자 또는 서비스 인스턴스를 알지 못했고, 데이터에 보편적인 트리 구조를 강제하지도 않았다. 그 지식은 구체적인 사양이 공급했다.RFC 3982와 그상태 페이지는 도메인 레지스트리 유형을 정의했다.RFC 4698은 이후 주소 레지스트리 유형을 정의했다. 이들의 별도 스키마는 코어 주변의 중복이 아니라, 의미가 의도된 위치였다.

가장 뚜렷한 경계는 조회와 검색 사이에 나타났다. 설계 부록에서 조회는 하나의 색인에 대한 개별 값이었다. 코어의lookupEntity연산은 레지스트리 유형, 주체 클래스 및 주체 이름을 지정했다. 부분 값을 다루거나, 여러 색인을 다루거나, 하나의 색인에 여러 질의를 수행하는 모든 것은 검색이 되었다. IRIS는 모든 레지스트리 유형을 위한 단일 표준 검색 언어를 정의하지 않았다. 각 레지스트리 유형은 자신의 데이터와 운영 제약에 맞는 검색을 정의했다.

이 선택은 매력적인 약속을 거부한 것이었다. RFC 3981은 한 절을 “범용 클라이언트의 유혹(The Lure of a Universal Client)”이라고 제목 붙였다. 범용 클라이언트는 조회를 수행하고 응답을 대충 표시할 수 있었다. 그러나 검색을 잘 하거나 결과를 유용하게 표시하려면 데이터에 대한 구체적 지식이 필요했다. 공통 질의 언어를 추가한다고 그 지식 요구가 사라지지 않았다. 사용자는 여전히 문제 도메인을 이해해야 하면서, 클라이언트는 언어의 최소공통분모를 통해 사용자 의도를 번역하도록 강제받을 뿐이었다.

서버 측 반론은 더 구체적이었다. IRIS는 통제된 기업 디렉터리만이 아니라 대중을 대상으로 하는 레지스트리를 다루었다. 부분 값을 여러 색인에 걸쳐 결합할 만큼 유연한 언어는 고급 사용자와 악의적 사용자 모두에게 유용했다. 운영자는 서비스를 유지하기 위해 비용이 큰 질의 패턴을 비활성화해야 했다. 명목상 공통인 언어는 결국 실제로는 공통으로 작동하지 않는 기능을 노출하게 된다. 강제된 보편적 데이터 관계는 또 다른 비용을 낳았다. 서버는 레지스트리의 실제 관계나 서비스 수준 요구에 맞지 않는 인위적 모델로 원래 저장소를 변환하라는 요구를 받을 수 있었다.

이것은 모든 범용 질의 언어가 안전하지 않다는 증명이 아니라 하나의 절충이었다.RFC 3707과 그상태 기록은 IRIS에 앞선 CRISP 요구사항을 담고 있었는데, 여기에는 검색, 분산 referral, 버전 관리 및 악의적 사용자가 포함되었다. RFC 3981은 그 우려를 특정한 공개 레지스트리 아키텍처에 적용했다. 동결된 기록에는 악용 빈도, 구현 비용 또는 채택에 대한 측정치가 없다.

심지어 범용 referral 기조 장치조차 증거의 차이를 보존했다. 주체 참조는 서버가 다른 주체에 대한 구체적 지식을 갖고 있음을 의미했다. 검색 연속(search continuation)은 다른 권위가 클라이언트가 찾는 것을 보유하고 있을 수 있음을 뜻했다 — 다른 것을 반환하거나 아무것도 반환하지 않을 수도 있었다. 클라이언트는 반복된 순회가 referral 루프를 만들 수 있으므로 어느 응답이든 한 번만 따르도록 권고받았다. 따라서 연속을 수신했다는 사실이 참조 대상이 도달 가능하거나, 원하는 기록에 대해 권위 있거나, 답을 낼 수 있음을 증명하지는 않았다.

오류 어휘는 더 많은 경계를 보이게 유지했다.invalidName은 구문을,invalidSearch는 의미론을,queryNotSupported는 서버 능력을,limitExceeded는 허용된 자원 사용을,nameNotFound는 선택된 색인을, 그리고permissionDenied는 제공된 인증이 결과 항목을 승인하지 않았음을 각각 나타냈다. 유효한 XML 메시지조차도 잘못된 질의, 지원되지 않는 질의, 비용이 큰 질의, 무권한 질의 또는 존재하지 않는 이름에 대한 조회일 수 있었다.

전송 모듈화 역시 같은 원칙을 따랐다.RFC 3983과 그상태 기록은 IRIS를 BEEP에 매핑했다.RFC 4992는 이후 XML을 청크 단위로 파이프라인하는 TCP 전송 프로토콜로 RFC 3981을 갱신했다. 그상태,정정 기록및Datatracker 기록이 이 갱신을 확립한다. 어느 전송도 코어를 보편적 레지스트리 스키마로 만들지 않았다. 인증과 프레이밍은 도메인 또는 주소 질의가 무엇을 의미하는지에 대한 권위를 획득하지 않고도 바뀔 수 있었다.

현재IANA URI 스킴 레지스트리는iris와 관련 전송 스킴을 기록하고 있으며,IETF XML 레지스트리는iris1네임스페이스를 보유하고 있다. 이것들은 내구성 있는 프로토콜 등록 사실이다. 운영 중인 서버, 광범위한 배포, 성공한 질의 또는 이후 등록 데이터 프로토콜에 대한 인과 서사의 증거가 아니다.

따라서 RFC 3981의 역사적 기여는 아키텍처적 절제였다. 서로 다른 레지스트리 시스템이 유형을 식별하고, 봉투를 교환하고, 자신 너머를 가리킬 수 있는 방식을 표준화하면서, 그 내용이 하나의 어휘나 그래프를 공유한다고 주장하지 않았다. 범용 클라이언트는 미끼로 남았다. 구문은 공통일 수 있지만 이해는 지역적이기 때문이다.

출처