요약

  • RFC 1274는 1991년 11월, 구현에 독립적인 COSINE 및 인터넷 X.500 파일럿 스키마를 위한 IAB 표준 트랙 규격으로 발표되었다. 이 문서는 표준 X.500 정의가 유용하지만 대규모 파일럿에는 불충분하며, 공통 정의를 각 사이트가 사적으로 반복하면 원격 시스템이 그 의미를 파악할 방법이 없어진다고 주장했다.
  • 일부러 절제된 적합성 기준을 설정했다. DSA는 명시된 값을 저장할 수 있어야 했고, DUA는 각 유형을 식별할 수 있어야 했다. 정확한 매칭, 객체 클래스 강제, 올바른 표시, 이전 버전과의 호환성은 요구 사항이 아니라 바람직한 동작이었다. 클래스는 선택적 속성으로 강화될 수 있었지만, 필수 속성 유형을 바꾸려면 새 클래스를 만들고 기존 클래스를 만료시켜야 했다.

공유된 이름이 유용했던 이유는 사적 반복이 의미를 잃었기 때문이다

RFC 1274는 모든 디렉터리가 동일해야 한다는 믿음에서 출발하지 않았다. 지역적, 난해하고 고도로 실험적인 요구는 사적 영역에 남아야 한다는 점을 인정했다. 그러나 대규모 파일럿에서는 모든 사이트가 같은 공통 인물·조직·서비스 기술에 대해 사적 버전을 만들어 내면 전체가 이해할 수 없는 상태가 된다. 원격 시스템은 익숙해 보이는 필드를 받아도 그 사적 유형이 무엇을 의미하는지 알아낼 믿을 만한 방법이 없을 수 있었다.

따라서 제안된 스키마는 조정 장치였다. 같은 반복적 필요를 지원하는 사이트들이 공통 정의를 사용하도록 하고, 본질적으로 유사한 실세계 대상에 대해 중복 유형을 만들지 않도록 절차에 요청했다. 이는 어휘의 확보일 뿐 권한의 이전이 아니다. 스키마는 어떤 유형이 디렉터리 시스템 안에서 어떻게 이름 붙고 기술되는지를 정할 뿐, 특정 값이 참이거나, 최신이거나, 권한을 받았거나, 완전하거나, 공개해도 안전하다는 것을 확립하지 않는다.

이 한계가 중요한 이유는 잘 알려진 레이블이 실제보다 강해 보일 수 있기 때문이다. 두 시스템이 같은 속성 이름을 사용한다는 사실은 독자에게 공통 용어를 채택했음을 알려줄 뿐이다. 그 값이 같은 방법으로 수집되었는지, 같은 주의로 매칭되었는지, 기술된 인물이나 기관을 대변할 권리가 있는지는 보여주지 않는다.

저장 가능성과 식별 가능성은 호환성 하한선이었다

적합성 절은 그 협소함을 명시한다. 적합성을 주장하는 디렉터리 시스템 에이전트(Directory System Agent)는 나열된 속성 및 객체 클래스 값을 저장할 수 있어야 했다. 디렉터리 사용자 에이전트(Directory User Agent)는 각 유형을 적절한 표현으로 사용자에게 식별해 주어야 했다. 대형 값에는 단서가 붙었다. 적합 DSA가 이를 저장할 필요는 없고, DUA가 표시할 필요도 없지만, 존재 자체는 표시해야 했다.

이 요구 사항들은 의미가 있다. 저장이 없으면 공통 스키마는 사이트 간에 이동할 수 없고, 유형 식별이 없으면 사용자는 어떤 종류의 값이 제시되는지 알 수 없다. 그러나 이 RFC는 그 기준선을 모든 값이 중요한 모든 의미에서 이해되었다는 주장으로 바꾸지 않았다.

시스템은 그 뒤에 있는 세계를 검증하지 않고도 필드를 담을 수 있다. 클라이언트는 값을 올바르게 렌더링하지 않고도 유형을 명명할 수 있다. 디렉터리 레코드는 그 이름이 가리키는 대상의 신원, 위임, 프라이버시 처리 또는 현재 상태를 입증하지 않고도 접근 가능할 수 있다. RFC 1274는 어휘를 공통으로 만들었다고 해서 이러한 구분을 지우지 않았다.

바람직한 동작은 완성된 의미론적 주장이 아니었다

문서는 바람직하지만 요구되지 않은 네 가지를 나열한다. 정의된 모든 문법에서의 정확한 매칭, 암시된 객체 클래스 스키마의 강제, DUA에 의한 올바른 표시, 이전 스키마 버전과의 호환성이 그것이다. 이 목록은 공유된 정의만으로 보장할 수 없었던 것들에 대한 몹시 가치 있는 역사적 지도다.

정확한 매칭은 시스템이 값을 어떻게 비교하는지에 관한 것이다. 강제는 시스템이 정의가 제시하는 클래스 규칙을 실제로 존중하는지에 관한 것이다. 표시는 인간 독자에게 무엇이 보이는지에 관한 것이다. 호환성은 새 버전이 구버전과 계속 작동하는지에 관한 것이다. 각각은 스키마와 관련되지만, 시스템이 속성을 저장하거나 유형 이름을 출력할 수 있다는 이유만으로 추론될 수는 없다.

이 경계는 기술적일 뿐 아니라 증거적이기도 하다. 표시된 디렉터리 항목은 특정 시스템이 특정 저장된 값을 렌더링했다는 증거다. 별도의 뒷받침 없이는 그 값이 정확하다는, 구현이 그것을 올바르게 매칭했다는, 클래스 규칙이 강제되었다는, 실세계 주체가 그 항목을 승인했다는 증거가 아니다.

선택적 성장은 정체성을 보존할 수 있었다. 필수 변경은 그렇지 못했다

RFC 1274의 변경 절차는 더 조용한 혼란을 막았다. 기존 객체 클래스가 추가적인 선택적 속성만 얻는다면 클래스는 강화될 수 있었다. 기존 인스턴스는 그 클래스의 인스턴스로 남기 위해 새로 의무화된 사실을 갖출 필요가 없었다.

규칙은 필수 속성 유형이 바뀌는 경우 달라진다. 이 RFC는 모든 기존 인스턴스에 요구되는 의미를 조용히 수정하는 대신, 새 객체 클래스를 만들고 원래 클래스를 만료시키는 방식을 제안했다. 이는 외형적 버전 레이블이 아니다. 필수 속성은 클래스에 속하는 조건에 참여한다. 그것을 바꾸면 낡은 공유 식별자가 다른 의미론적 약속을 기술하기 시작한다.

새 클래스 규칙은 감사 가능한 경계를 남긴다. 독자는 어떤 클래스가 사용되었는지, 그 시점에 어떤 속성이 필수였는지, 어떤 항목이 새 정의로 넘어갔는지 물을 수 있다. 조용한 재작성은 과거 기록이 실제로는 갖고 있지 않던 조건을 언제나 갖고 있었던 것처럼 보이게 만든다.

스키마는 어휘를 다스렸다. 기술하는 세계가 아니라

파일럿의 설계는 마지막 분리를 드러낸다. 공통 정의는 독립된 시스템 간 교환을 개선할 수 있다. 그러나 주소의 진실, 인물의 신원, 디렉터리 관리자의 권한, 값의 프라이버시, 특정 배포에서의 조회 결과를 결정하지는 않는다.

그 절제야말로 이 문서에 지속적인 역사적 가치를 부여한다. 스키마는 그 언어가 이름 붙이는 것 자체가 되겠다고 주장하지 않으면서 언어를 조정할 수 있었다. 진화 규칙도 같은 일을 했다. 선택적 다듬이에 길을 열어 주되, 바뀐 필수 의미가 공개 없이 낡은 클래스의 역사를 빌릴 수는 없도록 했다.

출처와 증거의 한계

이 글은RFC 1274 —The COSINE and Internet X.500를 사용한다. 이 출처는 1991년 파일럿 스키마의 지위와 범위, 공통 대 지역 정의 정책, 적합성 요구 사항과 바람직한 동작, 선택적 대 필수 클래스 변경 절차를 뒷받침한다. 이 문서는 실존하는 디렉터리, 특정 DSA나 DUA, 디렉터리 값의 정확성, 신원, 승인, 프라이버시, 매칭, 강제, 표시, 호환성 또는 현재 서비스 결과를 확립하지 않는다.