요약

  • RFC 3367은 일반 명칭(common name) 서비스를 질의하기 위한 최소한의 프로토콜을 표준화했으며, 기능을 기술하고, 결과와 참조(referral)를 전달하고, 서비스와 데이터셋의 출처(provenance)를 보존했다.
  • 이 프로토콜은 발견(discovery), 공급자 선택, 등록, 소유권, 고유성을 의도적으로 범위 밖에 두었다. 프로토콜은 어떤 서비스가 답할 권한이 있는지를 결정하지 않고도 답변을 상호운용 가능하게 만들 수 있었다.

1990년대 후반, 브라우저 주소 필드는 URL을 입력하는 곳 그 이상이 되어 가고 있었다. 사람들은 회사 이름, 책 제목, 평범한 문구를 입력했다. 브라우저와 포털은 그 입력을 탐색이나 검색으로 해석할 수 있었지만, 그들의 백엔드 서비스에는 특정 명칭 질의를 교환할 공유된 방법이 없었다.

RFC 3367은 바로 그 인터페이스를 다루었다. 일반 명칭 해석 프로토콜(Common Name Resolution Protocol), 약칭 CNRP는 인간의 문구를 인터넷 자원과 연관시키는 서비스를 위해 클라이언트에 공통의 XML 요청·응답 언어를 제공했다. 이는 2002년 표준 트랙에 발표되었다. 그 야망은 새로운 글로벌 명명 체계보다 더 좁으면서도 더 본질을 드러내는 것이었다.

프로토콜의 용어로, 일반 명칭(common name)은 부과된 통사 구조가 없는 단어나 문구였다. 회사 이름, 상표명, 사람의 이름, 책 제목일 수 있었다. URI와 달리 표준화된 구조를 담고 있지 않았다. URN과 달리 자원과의 연관이 고유하거나 영속적일 필요가 없었다.

이 차이는 초안 작성의 누락이 아니었다. RFC 3367은 해석 서비스가 하나 이상 존재할 것으로 예상했고, 어떤 일반 명칭이라도 어떤 서비스에서든 사용될 수 있도록 허용했다. 한 서비스는 조직에 특화하고, 다른 서비스는 책에 특화할 수 있었으며, 포털은 여러 서비스를 통합할 수 있었다. 따라서 동일한 문구가 서로 다른 데이터셋에서 서로 다른 기록과 연관될 수 있었다.

CNRP는 클라이언트가 물어볼 곳을 확보한 다음에 일어나는 일을 표준화했다. 클라이언트는 서비스 설명을 요청하고, 서비스가 이해하는 속성을 학습하고, 질의를 보내고 결과 집합을 받을 수 있었다. 결과에는 자원 서술자, 상태 메시지, 참조(referral)가 포함될 수 있었다. 서비스 객체는 데이터셋과 서버를 기술했다. 여러 서비스를 통합하는 프록시는 어떤 서비스와 데이터셋이 각 항목을 만들었는지를 보존할 수 있었다.

공통 코어는 의도적으로 작았다. 모든 규격을 준수하는 서비스는 일반 명칭, 서비스 로컬 식별자, 자원 URI, 설명 같은 코어 속성을 이해했다. 추가 속성은 언어, 지리, 카테고리를 기술할 수 있었다. 서비스는 자신의 스키마를 공개할 수 있어서, 클라이언트가 모든 공급자가 정보를 같은 방식으로 조직한다고 가장할 필요가 없었다.

이 확장성에는 정밀한 한계가 있었다. 질의 속성은 힌트로 작동할 수 있었다. 사용자가 특정 언어나 지리를 선호할 수 있지만, 서비스가 모든 힌트를 같은 방식으로 해석해야 할 의무는 없었다. RFC 3367은 그 반응의 정도를 서비스 차별화 요소(service differentiator)라고 불렀다. 일부 속성이 무시되더라도 올바르게 인코딩된 질의는 수용될 수 있었고, 부분 성공 상태는 그 차이를 공개할 수 있었다.

이는 개방된 인터넷 위의 SQL이 아니었다. 질의는 반환된 모든 항목이 모든 조건을 만족한다고 약속하지 않았다. 서비스에 선정 기준에 가장 가까운 결과를 요청하는 것이었다. 프로토콜은 컨테이너와 일부 의미론을 표준화하면서 순위 매기기, 커버리지, 그리고 상당 부분의 분류 동작은 서비스에 남겨 두었다.

이전의 맥락 문서인 RFC 2972는 제도적 경계를 이례적으로 명시적으로 만들었다. 서비스 발견과 선택, 서비스 관리, 명칭 등록, 명칭 소유권, 고유한 이름을 만들거나 보장하는 방법은 초기 프로토콜 범위 밖이었다. CNRP는 공급자가 선택된 후에 클라이언트와 공급자를 연결할 수 있었다. 공급자를 선택하지는 않았다.

이 경계가 중요한 이유는 선택이 바로 권한이 들어오는 지점이기 때문이다. 한 브라우저가 상업 디렉터리에 물어보도록 구성되고 다른 브라우저가 지역 공공 서비스에 물어보도록 구성되었다면, 둘 다 동일한 규격 준수 요청을 보내 서로 다른 유효한 바인딩을 받을 수 있었다. 프로토콜은 그 출처를 보존할 수 있었다. 어느 데이터셋이 전역적으로 권위 있다고 선언할 수는 없었다.

RFC 2972는 권위가 할당을 통제하는 사적 네임스페이스와, 사람 이름·지명·제목처럼 모호성이 본질적인 공적 네임스페이스를 구분했다. 이는 다수의 분류 체계를 예상했고, 자유 형식의 카테고리 키워드가 서비스 간 완전한 상호운용성을 보장하지 못할 수 있음조차 인정했다. 질의를 표준화하는 것이 질의되는 세계를 표준화하는 것은 아니었다.

RFC 3368은go:URI 스킴을 통해 같은 경계를 드러냈다. 한 형식은 특정 서버를 식별할 수 있었다. 다른 형식은 서버를 명명하지 않고 일반 명칭 질의를 표현하여, 클라이언트가 구성한 하나 이상의 서비스로 보내질 수 있었다. URI는 질문을 담았다. 응답하는 기관은 여전히 클라이언트 구성이 공급했다.

이는 처음 보이는 것보다 더 영향력 있는 설계다. 서버리스go:URI는 두 대의 기기에서 동일할 수 있으면서 서로 다르게 해석될 수 있었는데, 그들의 서비스 목록이 다르기 때문이었다. 복사 가능한 식별자가 반드시 복사 가능한 권한 선택을 담고 있는 것은 아니었다. 해석은 문자열에 일부 담기고, 로컬 구성에 일부 담겼다.

전송 부트스트랩은 더 구체적이었다. 범용 클라이언트와 서버는 초기 접촉을 위해 포트 1096에서 HTTP를 지원해야 했다. 특수화된 응용은 다른 서버, 포트, 전송을 정의할 수 있었다. 접촉된 후, 서비스 설명은 대안을 광고할 수 있었다. 이는 알려진 서비스와의 교환을 시작하는 기계적 문제를 해결했다. 클라이언트가 그 서비스를 신뢰하거나 선호하게 되는 방법은 해결하지 않았다.

참조(referral)는 권한 그래프를 확장했다. 서비스는 일부 결과를 반환하면서 클라이언트에게 다른 서비스에 더 많은 것이 있을 수 있다고 알릴 수 있었다. 참조를 따를 수 있는 쪽은 서버가 아니라 클라이언트였다. 따라서 CNRP는 서비스 및 데이터셋 참조를 명시하고 루프 감지를 기술했다. 클라이언트는 접촉한 호스트명뿐 아니라 방문한 서비스·데이터셋 쌍을 기억해야 했다.

부분 성공은 일급 결과였다. 서비스는 지원되지 않는 속성이 무시되었음을, 요청된 데이터셋 중 하나만 사용되었음을, 참조 서버를 사용할 수 없음을 보고할 수 있었다. 이는 불완전성을 가시화했다. 그러나 모든 클라이언트가 그 한계를 인간에게 똑같이 잘 제시하게 만들지는 않았다.

보안은 같은 의존성을 한 층 더 깊이 드러냈다. RFC 3367은 중간자(man-in-the-middle) 공격, 위조된 Service 객체, 그리고 또 하나의 간접 계층으로 발생하는 서비스 거부를 식별했다. Service 객체에 서명할 수 있었지만, 검증에는 권위 있는 공개 키가 필요했다. 클라이언트가 그 키를 얻는 방법은 서비스 발견 문제에 의존하기 때문에 범위 밖으로 선언되었다.

서명은 신뢰 앵커가 선택된 후의 진술을 보호할 수 있었다. 신뢰 앵커를 선택할 수는 없었다. 이것이 압축된 형태로 담긴 이 프로토콜의 핵심 역사적 교훈이다. 암호학적 유효성과 제도적 권위는 만나지만, 같은 작업이 아니다.

현재 IANA URI 스킴 레지스트리는go를 영구(Permanent) 스킴으로 등록하고 RFC 3368을 인용한다. RFC 3367은 여전히 제안 표준(Proposed Standard)이다. 이들은 내구성 있는 레지스트리 및 표준 사실이다. 그러나 이 사실들은 몇 개의 브라우저가 스킴을 구현했는지, 몇 개의 CNRP 서비스가 운영되었는지, 얼마나 많은 트래픽을 처리했는지, 지금 누구라도 그것에 의존하는지를 측정하지 않는다.

배포 센서스의 부재는 쉬운 흥망성쇠 서사를 막는다. RFC 2972는 포털과 브라우저 벤더에 의한 통합을 예상했지만, 예상은 채택이 아니다. 마찬가지로, 등록된 스킴은 브라우저 능력 수령 확인서가 아니다. 역사적 정확성을 위해서는 제안, 레지스트리 보관, 구현, 구성, 운영 중인 서비스, 사용자 결과를 서로 분리해 두어야 한다.

인접한 URI 및 URN 작업은 CNRP를 그 체계에 붕괴시키지 않고 위치시키는 데 도움이 된다. RFC 2396은 일반 URI 구문을 기술했고, RFC 3986은 나중에 그 기초를 갱신했다. RFC 2276과 RFC 2483은 URN 주변의 해석 및 해석 서비스를 논의했다. RFC 3401은 이후의 동적 위임 발견 체계(Dynamic Delegation Discovery System) 계열을 기술했다. 이 문서들은 인간의 식별자나 영속적 식별자를 실행 가능한 자원으로 번역하는 일에 몰두하던 시기를 보여준다. 이들은 특정 배포에서 한 메커니즘이 다른 메커니즘을 대체했다는 것을 증명하지 않는다.

Lu Heng의 두 에세이가 공개된 분석적 렌즈를 제공한다. “Minimum Initial Specification(최소 초기 명세)”은 작고 결정론적인 공통 계층과 그 이후의 로컬 결정을 주장한다. CNRP는 거의 문자 그대로의 사례다. 상호운용 가능한 코어는 교환을 표준화하면서 선택, 소유권, 미래의 서비스 동작은 밖에 남겨 두었다. “On Reality Layers(현실의 계층에 대하여)”는 유효한 프로토콜 응답이 사용자가 의도한 현실로 오인되지 않도록 막는다. 프로토콜 규격 준수, 서비스 식별, 데이터셋 출처, 반환된 바인딩, 성공한 목적지는 서로 구별되는 계층이다.

그 아키텍처는 복수의 답변에 대해 정직했다. 단일 무차별 목록 뒤에 통합을 숨기는 대신 서비스 출처를 보존했다. 힌트를 최선의 노력으로, 부분 결과를 보고 가능한 상태로 다루었다. 참조 순회에 루프 감지를 배치했다. 이것들은 하나의 전 지구적 디렉터리를 몰래 가정한 설계의 속성이 아니다.

그러나 그 정직함이 권력을 없애지는 않았다. 서비스 목록을 구성하는 자가 어느 데이터셋이 답할 수 있는지, 어느 카테고리가 이해되는지, 어느 참조가 따라지는지, 어느 자원이 나타나는지에 영향을 주었다. 중립적인 와이어 형식은 통합 비용을 낮출 수 있으면서도 배분과 선택의 권력은 다른 곳에 남겨 둘 수 있다.

따라서 RFC 3367은 인터넷 역사에서 유용한 경계를 표시한다. 질문은 표준화될 수 있었다. 여기 문구와 맥락과 결과의 형태가 있다. 응답자는 다른 거버넌스 결정을 하지 않고서는 표준화될 수 없었다. CNRP는 그 선에서 멈추었고, 클라이언트가 선이 있다는 것을 알 수 있을 만큼의 출처를 가시화했다.

출처