요약

  • RFC 3404는 URI 해석을 형식화된 요청으로 정의했다.I2L,I2R,I2C,I2N은 각각 위치, 자원 인스턴스, 서술, 영속적 이름을 요청했으며, 단수형과 복수형은 카디널리티도 함께 전달했다.
  • S,A,U는 다음 DDDS 단계에 사용되는 표현을 서술했다.P는 범주적으로 다른 동작을 했다. 즉 DDDS를 벗어나 응용별 처리로 넘어갔다. 여전히 디스커버리는 리졸버나 반환된 자원을 인증하지 않았다.

리졸버 로그에서 위험한 단어는 흔히 오류 코드가 아니다. "성공"이다. 시스템은 호출자가 물어보지 않은 질문에 성공적으로 답할 수 있다. 응용이 한 작품에 대한 서술을 원하는데 사본을 내려받을 수 있는 한 곳의 위치를 받았다면, 이 조회는 단순히 형식이 달라진 것이 아니라 의미 자체가 바뀐 것이다.

2002년 10월에 Standards Track으로 발행된 RFC 3404는 URI 및 URN 해석을 위한 동적 위임 디스커버리 시스템(DDDS) 응용 안에서 바로 이 구별을 다루었다. 이 문서는 다섯 개 문서로 이루어진 DDDS 시리즈에 속한다. RFC 3401은 계열을 소개했고, RFC 3402는 알고리즘을 정의했으며, RFC 3403은 규칙을 DNS NAPTR 레코드로 매핑했고, RFC 3404는 해석 응용을 정의했고, RFC 3405는uri.arpa.와urn.arpa.트리를 배정했다.

이 아키텍처는 응용 고유 문자열(Application Unique String)에서 시작했다. 일반 URI 해석에서는 절대 URI가 정규화되어 응용이 기대하는 형식으로 인코딩되었고, 그 스킴이 첫 번째 잘 알려진 키(First Well Known Key)를 제공했다. DNS 키는 그 스킴을uri.arpa.에 덧붙였다. URN 해석은 대신 네임스페이스 식별자와urn.arpa.를 사용했다. 두 경우 모두 NAPTR 규칙은 처리가 최종 결과 또는 다른 시스템에 도달할 때까지 재작성하거나 위임할 수 있었다.

두 응용은 하나의 사양으로 함께 서술될 만큼 기술적으로 동일했다. 그러나 전략적 이유로 운영상으로는 분리되어 있었다. URN 해석에는 이미 단축 모델이 있었고, 보편적 URI 리졸버의 채택에 의존하도록 만들어서는 안 되었다. 잘 알려진 키를 분리함으로써 네임스페이스는 모든 URI 스킴이 같은 시스템에 합류하기를 기다리지 않고도 유용한 해석을 배포할 수 있었다.

Services 필드가 빠져 있던 의미 유형을 전달했다.I2L은 URI-위치를 의미하며 하나의 위치 URI를 반환했고,I2Ls는 하나 이상을 허용했다.I2R과I2Rs는 자원의 인스턴스를 반환했다.I2C는 서술을 반환했고,I2N은 URN을 반환했다. 마지막 경우에는 중요한 경고가 함께 왔다. 두 URN의 동등성 비교는 사소하지 않을 수 있다는 것이었다. 반환된 문자열의 겉보기 단순함이 네임스페이스별 규칙을 제거하지는 않았다.

이들은 "관련된 것은 무엇이든 달라"는 동의어가 아니었다. 위치는 자원을 어디서 얻을 수 있는지에 대한 진술이다. 자원 인스턴스는 해석 프로토콜을 통해 전달되는 그 자체이다. 서술은 그에 대한 메타데이터다. 이름은 현재 위치와 독립적으로 동일성을 보존하려는 것이다. 같은 식별자가 네 가지 연산을 모두 지원할 수 있지만, 하나에 대한 근거가 다른 하나를 충족하지는 않는다.

카디널리티도 계약의 일부였다.I2Ls와I2Rs의 소문자s는 응답이 여러 결과를 담을 수 있음을 의미했다. 조용히 첫 항목을 선택하는 소비자는 집합 값 응답을 단일 값으로 바꾸며 선택 정책까지 스스로 가정한 것이다. 따라서 접수 기록에는 요청된 서비스, 응답 클래스, 반환된 모든 결과, 소비자의 최종 선택이 기록되어야 했다.

RFC 3404는 해석 서비스 앞에 선택적 프로토콜 접두어를 허용했다. 그러나 프로토콜 이름은 URI 해석 계약이 아니었다. 사양은 요청이 원하는 서비스를 어떻게 인코딩하는지, 응답이 그것을 어떻게 표현하는지를 별도로 정의할 것을 요구했다. "HTTP"라고 말하는 것은 프로토콜 계열을 식별할 뿐, 연산이 위치·콘텐츠·메타데이터 중 무엇을 요청하는지, 상태와 미디어 타입이 무엇을 의미하는지, 여러 값이 어떻게 직렬화되는지 말해 주지 않았다.

이 요구사항은 오늘날에도 유용한 경계를 드러낸다. 서비스 디스커버리는 유능한 엔드포인트를 찾을 수 있다. 전송 계층의 라벨로 응용 프로토콜을 만들어 낼 수는 없다. 상호 운용성은 광고된 능력을 관찰 가능한 결과와 연결하는 요청·응답 의미론을 필요로 한다.

Flags 필드는 또 다른 차원을 서술했다.S,A,U는 DDDS 종단 플래그였다.S는 규칙 출력이 SRV 질의를 위한 도메인 이름임을,A는 도메인 이름에 대한 주소 레코드로 이어짐을,U는 URI를 산출함을 나타냈다. 이들이 종단이라 불린 이유는 DDDS 루프가 멈추기 때문이었고, 이후의 리졸버나 프로토콜에는 여전히 상당한 작업이 남아 있을 수 있었다.

P는 동료 글자처럼 보였지만 DDDS 종단 플래그가 아니었다.P는 나머지 처리가 응용별이며 더 이상 DDDS 개념을 따르지 않음을 선언했다. 이는 또 하나의 출력 인코딩이 아니라 제어 경계에 대한 진술이다. DDDS 안에서P를 종단이라 부르면 다른 규칙 집합이 권한을 가져갔다는 사실이 가려진다.

2002년 응용에서 네 플래그는 상호 배타적이었지만, RFC는 구현자에게 이 필드가 영원히 길이 0 또는 1일 것이라고 가정하지 말라고 경고했다. 이후의 응용은 조합을 정의할 수 있었다. 알려지지 않은 플래그는 레코드를 무시하고 처리를 계속하는 원인이 되어야 했다. 이 검사는 정상적인 정렬보다 먼저 수행되었는데, 알려지지 않은 플래그가 이후 모든 필드의 해석 방식을 바꿀 수 있기 때문이었다.

빈 Services 문자열도 유효했다. 위임 체인 초기에 규칙 게시자는 최종 리졸버가 어떤 프로토콜과 서비스를 지원하는지 아직 알지 못할 수 있었다. 비어 있다는 것이 오 형식이거나 의미상 보편적이라는 뜻은 아니었다. 이 규칙이 최종 서비스 능력이 확정되기 전에 위임을 넘겼다는 뜻이었다.

RFC 3404는 하나의 신중히 경계 지어진 최적화를 제공했다. 같은ORDER를 공유하는 레코드 안에서 클라이언트는 첫 번째 선호를 맹목적으로 따르는 대신 더 적합한 서비스를 탐색할 수 있었다. 그러나 선택된 레코드는 여전히 기본 DDDS 알고리즘의 입력과 출력을 보존해야 했다. 이 탐색은 위임 경로를 넘어설 수 없고, 일치 후 더 높은ORDER를 살펴볼 수 없으며, 결정적 위임을 제약 없는 카탈로그 질의로 바꿀 수 없었다.

이 구별이 중요한 이유는 "더 나은 서비스"는 클라이언트의 판단인 반면,ORDER는 게시된 권한을 인코딩하기 때문이다. 이를 혼동하면 로컬 능력이 관리자의 위임 구조를 침식한다. 클라이언트는 동등한 옵션 중 하나의 프로토콜을 선호할 수 있지만, 다른 권한 계층의 더 편한 엔드포인트를 동등한 것으로 취급할 수는 없다.

추가 SRV 또는 주소 레코드가 답변에 수반되어 왕복을 줄일 수 있었다. 이들은 오직 최적화일 뿐이었다. 네임서버가 이를 생략하더라도 응용은 동작해야 했다. 검증자는 "리졸버가 다음 이름을 찾았다"와 "클라이언트가 편리한 글루를 함께 받았다", 그리고 "다운스트림 연결이 성공했다"를 구별해야 한다.

보안도 같은 경계를 따라 나뉘었다. 리졸버를 찾는 것은 그와 안전하게 통신하는 방법을 정의하지 않았다. 그 책임은 각 해석 프로토콜에 있었다.uri.arpa.와urn.arpa.의 DNS 관리는 가용성, 스푸핑, 위임 위험을 수반했다. 검증된 DNS 경로조차도 응용 응답을 인증하거나, 자원이 의도된 것임을 증명하거나, 서술이 최신임을 확립하지 못했다.

정규 표현식은 로컬 실행 위험을 더했다. 구현은 표현식을 위험한 능력을 가진 환경에 맹목적으로 넘기는 대신 정상성을 검사해야 했다. 서명되었거나 올바르게 위임된 규칙도 실행에 안전하지 않을 수 있었다. 진위성과 안전한 해석은 별개의 근거였다.

RFC Editor는 현재 세 건의 편집 정오표를 나열하고 있다. 검증된 정오표 282와 787은 RFC 3404 자신의 "추가 정보(Additional Information)" 처리를 가리켜야 하는 참조가 RFC 3403을 가리키고 있는 경우를 수정한다. 문서 갱신 보류 중인 정오표 2923은 4절의 참조 번호를 수정한다. 어느 것도 플래그 모델, 형식화된 해석 서비스, 그 카디널리티를 바꾸지 않는다.

따라서 RFC 3404에 대한 유용한 운영 접수 기록은 정규화된 입력, 스킴 또는 네임스페이스, 첫 번째 키, DNS 질의, 전체 NAPTR 집합, 알려진 플래그 판정, 프로토콜, 요청된 해석 서비스, 카디널리티, 동일ORDER선택, 선택된 규칙,S/A/U/P인계, 다음 질의 또는 URI, 리졸버 요청 인코딩, 인증된 피어, 응답 콘텐츠 타입, 반환된 객체 클래스, 소비자 결과를 보존한다.

Lu Heng의 최소 초기 사양(Minimum Initial Specification) 원칙은 이 문서가 하나의 보편적 리졸버 대신 이 좁은 경계들을 표준화한 이유를 명확히 한다. 공유 라벨은 출력이 정확히 형식화될 때만 유용했고, 프로토콜 세부는 로컬에 남아 진화할 수 있었다. 이어서 실행 코드 우선(Running-Code Primacy)이 검증을 제공한다. 같은 식별자에게 위치, 자원, 서술을 각각 요청하고, Additional 데이터를 제거하고, 알려지지 않은 플래그를 도입하고, 동일ORDER능력을 변화시키고, 계약이 허용하는 곳에서만 구현이 바뀌는지 확인하면 된다.

RFC 3404는 모든 식별자가 모든 답을 낼 수 있다고 약속하지 않았다. 대신 구현이 어떤 답을 구하는지, 어떤 인계를 따랐는지 말하도록 만들었다. 이 규율은 "해석 성공"을 안심시키지만 텅 빈 상태에서 검사 가능한 주장으로 바꾸었다.

출처