요약

  • RFC 3383은 모든 LDAP 확장을 하나의 승인 절차 뒤에 두지 않았다. Standards Action, 전문가 검토, 사양 필수, 선착순, 실험용 및 사적 사용 공간을 서로 다른 상호운용성 리스크에 맞춰 배분했다.
  • 등록된 식별자는 조정 근거이지, 그 확장이 구현되었거나 안전하거나 상호운용 가능하다는 증명이 아니었다. 그 가치는 식별자에 붙은 공개 사양, 관리 주체, 검토 경로와 변경 관리 이력에서 나왔다.

두 개발자가 모두 LDAP을 확장 가능하게 만들면서도 여전히 제품끼리 통신하지 못할 수 있다. 서로 같은 결과 코드 정수를 다른 의미에 할당하면, 전송 값은 완벽하게 디코딩 가능한 채로 의미가 둘로 갈라진다. 위험은 프로토콜에 공간이 없다는 것이 아니다. 공유 공간이 두 번 차질 수 있다는 것이다.

2002년 9월에 Best Current Practice 64로 발표된 RFC 3383은 이를 기술적 결과가 있는 거버넌스 문제로 다뤘다. LDAP은 이미 새로운 연산, 기존 연산의 확장, 확장 가능한 스키마를 지원하고 있었다. 이 문서는 그러한 추가 요소들의 식별자가 어떻게 충돌로 유연성을 변질시키지 않고 공통 사용에 들어와야 하는지를 물었다.

그 답은 단일 레지스트리 대기열이 아니었다. 서로 다른 네임스페이스에는 서로 다른 정책이 적용됐다. LDAP 메시지 유형, 결과 코드, 인증 방식, 프로토콜 메커니즘, 객체 식별자 기술자(descriptor), AttributeDescription 옵션은 동일한 리스크를 지니지 않았다. RFC 3383은 따라서 각각에 서로 다른 정도의 마찰을 배정했다.

IETF가 개발하는 요소의 경우, 사양은 Internet Directory Numbers 아크 아래에서 하나의 객체 식별자(OID)를 요청할 수 있었다. 할당에는 사양 필수 조건의 전문가 검토가 필요했다. 아크가 할당되면 사양은 IANA에 개별 잎사귀마다 돌아오지 않고 필요한 만큼 하위 OID를 할당할 수 있었다. 레지스트리는 가지를 조정했고, 정의 문서가 그 아래의 로컬 트리를 통치했다.

다른 개발자들은 Internet Private Enterprise Number 아래의 OID를 포함해 적절히 위임된 어떤 OID든 사용할 수 있었다. 진행 중인 작업은 실험용 OID 아크를 사용하도록 권장됐는데, 이는 초기 구현이 나중에 공개 사양에 대해 선택될 식별자와 충돌하지 않도록 하기 위해서였다. 실험용 OID는 공개 사양에 등장해서는 안 되었다. 임시 차선은 목적지가 아니었기에 정확히 유용했다.

발견 가능한 프로토콜 메커니즘에는 또 다른 균형이 적용됐다. LDAP Root DSE 속성은 OID를 통해 지원하는 컨트롤과 확장을 광고할 수 있었다. 이러한 발견 가능한 메커니즘은 일반적으로 사양 필수 조건의 선착순 정책을 따랐고, 이는 완전한 표준화 동작 없이도 공개 기술 설명을 이용할 수 있게 했다. 반면 Standards Track 메커니즘은 Standards Action을 통해 등록되어야 했다.

이 구분은 흐리기 쉽고, 흐려서는 안 된다. 선착순은 기술적 품질을 인증하지 않았다. 사양 필수는 IETF 표준화를 의미하지 않았다. Standards Action은 배포를 증명하지 않았다. 각 정책은 어떤 증거와 검토가 존재해야 어떤 값이 특정 공유 공간을 차지할 수 있는지에 대한 더 좁은 질문에 답했다.

기술자(descriptor)는 숫자 OID 위에 사람이 읽을 수 있는 계층을 도입했다. 기술자는 대소문자를 구분하지 않는 짧은 이름이었고, 하나의 OID를 여러 이름이 참조할 수 있었다. 하이픈으로 끝나는 기술자는 이름 한 계열 전체를 예약할 수 있었다.x-로 시작하는 값은 사적 사용에 속하며 등록할 수 없었다.e-로 시작하는 값은 실험용으로 예약되고 선착순으로 사용됐다. 그 외의 기술자는 전문가 검토가 필요했다.

AttributeDescription 옵션도 유사한 구획을 따랐으며, 자체적인 길이 지침과 등록 정책을 가졌다. 여기서도x-는 사적 사용을,e-는 실험 차선을 표시했다. 그 외의 옵션은 Standards Action 또는 사양 필수 조건의 전문가 검토가 필요했다. 이 접두사는 장식이 아니었다. 어떤 이름이 다른 조정 약속 아래에 살고 있음을 선언했다.

숫자 공간은 리스크 배분을 더욱 선명하게 드러냈다. 결과 코드의 경우 0부터 1023까지의 값은 Standards Action이 필요했다. 1024부터 4095까지는 사양 필수 조건의 전문가 검토가 필요했다. 4096부터 16383까지는 선착순을 사용하며 실험용e-키워드와 짝을 이뤘다. 16384 이상의 값은x-키워드와 함께 사적 사용에 속하며 등록할 수 없었다.

인증 방식도 같은 숫자 구획을 사용하면서, COMMON, LIMITED USE, OBSOLETE라는 사용 분류를 추가했다. 공개적으로 이용 가능한 사양이 없는 방식은 COMMON으로 분류될 수 없었다. 새 등록이 곧바로 OBSOLETE로 들어올 수도 없었다. 따라서 레지스트리는 단순히 숫자 이상을 기록했다. 의도된 범위에 대한 주장을 기록했고, 그 주장 주위에 증거 조건을 둘렀다.

LDAP 메시지 유형에는 가장 엄격한 단순 규칙이 적용됐다. 새로운 값은 Standards Action이 필요했다. LDAP에는 이미 확장 가능한 메시지 메커니즘이 있었고, 이는 새 최상위 유형의 필요성을 줄였지만 없애지는 않았다. 봉투(envelope)의 기본 선택 공간을 바꾸는 일은 사적 실험에 이름을 붙이는 일과 다른 조정 비용을 지녔다.

RFC 3383은 또한 언제 레지스트리를 닫아야 하는지 알고 있었다. Directory Systems Names는 구별 이름(distinguished name)의 LDAPv2 문자열 표현에 사용되었다. LDAPv3는 다른 문법을 가진 OID 기술자를 사용했다. 새 Directory Systems Names는 더 이상 받지 않았지만, 기존 목록은 역사적 목적으로 공개된 채 유지되어야 했다. 폐쇄가 곧 지움을 요구하지는 않았다.

등록 절차가 정책을 작동 가능하게 만들었다. Standards Action 요청은 IESG 승인을 거쳤다. 전문가 검토 요청은 완성된 템플릿을 사용해 2주간의 공개 검토를 위해 게시됐다. 요청자가 양식을 수정하면 검토 기간은 다시 시작됐다. 목록상의 누구나 반대 의견을 제출할 수 있었다. 지정된 전문가가 요청을 승인해 전달하거나 거부했고, 그 결정에는 항소 절차가 있었다.

선착순 요청은 완성된 양식과 함께 IANA로 직접 제출됐다. 소유권 구조도 달랐다. Standards Action 값의 소유자는 IESG로 취급됐고, 전문가 검토 및 선착순 등록은 요청자가 소유했다. 이 소유자는 단순한 역사적 크레딧이 아니었다. 항목에 유지보수가 필요할 때 중요해졌다.

소유자는 새 등록과 동일한 제약과 검토 아래에서 등록을 갱신할 수 있었다. 소유자가 필요한 갱신을 할 수 없거나 하지 않으려는 경우, IESG가 소유권을 주장하여 기록을 복구할 수 있었다. 전문가 검토 이후 소유자가 등록 변경에 동의하지 않을 때, 타인의 중대한 반대 의견은 주석으로 첨부될 수 있었다. 조정에는 표의 마지막 칸만이 아니라 불일치의 기억도 포함됐다.

RFC 속 템플릿은 레지스트리가 무엇을 보존하려 했는지 드러낸다. 식별자, 설명, 사양, 연락처, 작성자 또는 변경 통제자, 사용 범위, 주석. 숫자만으로는 두 개의 깨끗한 할당이 동일해지는 것을 막을 수 있었지만, 그 값이 무엇을 의미하는지, 누가 정정할 수 있는지, 구현자가 어디서 기술적 계약을 찾아야 하는지는 설명할 수 없었다.

RFC 2434는 RFC 3383이 LDAP에 적용한 일반 등록 정책 어휘를 공급했다. RFC 8126은 이후 그 일반 지침과 용어를 갱신했다. 현재 IANA LDAP 파라미터 페이지들은 이 레지스트리가 여전히 살아있는 공개 표면임을 보여준다. 그러나 이를 2002년의 모든 필드와 절차가 그대로라는 증거, 또는 목록에 실린 모든 메커니즘이 활성 구현을 지녔다는 증거로 읽어서는 안 된다.

RFC 3377은 RFC 3383을 당시의 LDAPv3 기술 사양 옆에 위치시켰다. RFC 2251, RFC 2252, RFC 2255는 레지스트리 규칙이 참조한 프로토콜, 스키마, URL 확장 맥락을 공급했다. RFC 4510은 이후 수정된 LDAP 기술 사양을 기술했다. 이 연결들은 연대기와 의존성을 확립할 뿐, 채택 인구조사가 아니다.

지속적인 설계 아이디어는 차등적 마찰이다. 충돌이 핵심 메시지를 파열시킬 수 있는 공간에는 Standards Action이 요구됐다. 공개적으로 사양화된 확장에 유용한 공간에는 전문가 검토나 단순 할당을 사용할 수 있었다. 실험과 사적 배포에는 탈출 밸브가 남아 있었지만, 그 접두사와 범위는 타인에게 이를 전역적으로 조정된 공개 의미로 취급하지 말라고 경고했다.

이 배치는 두 가지 상반된 실패를 피했다. 모든 실험에 완전한 표준화를 요구하면 혁신이 절차 밖으로 밀려나거나 얼어붙게 된다. 모든 공유 값을 문서화 없이 주장할 수 있게 두면, 확장은 할당 순간에는 싸지만 이후 모든 상호운용성 실패에서 비싸진다. RFC 3383은 비용을 리스크가 사는 곳에 배치했다.

Lu Heng의 최소 초기 사양(minimum-initial-specification) 렌즈는 이 구조를 명확히 한다. 이 문서는 미래의 모든 LDAP 확장을 결정하려 하지 않았다. 미래의 결정이 로컬로 유지될 수 있는 가장 작은 거버넌스 기반을 정의했다. 구획, 정책, 템플릿, 소유자, 복구 경로. 초기 사양은 변경에 조정 비용이 전혀 없다는 가정 없이 변경을 가능하게 했다.

그의 현실 계층(reality-layers) 렌즈는 필요한 절제를 더한다. 할당, 등록, 사양, 구현, 배포, 성공적 협상, 사용자가 목격한 결과는 서로 다른 계층이다. 레지스트리 항목은 조정 계층에서 강력한 증거다. 소프트웨어가 출하되었거나, 보안 검토가 성공했거나, 두 구현이 같게 동작했다는 증거가 아니다.

RFC 3383의 역사적 기여는 확장성을 관리 책임(stewardship)으로 읽을 수 있게 만든 것이다. 식별자는 확장에 장소를 주었다. 정책은 공유 공간에 들어가기 전에 무엇을 공개해야 하는지 결정했다. 레지스트리는 할당 순간이 지난 후에도 의미, 소유자, 정정 경로가 발견 가능하도록 유지했다.

출처