요약

  • RFC 2079는 대소문자를 구분하고 다중 값을 가질 수 있는labeledURI속성과, 기존 X.500 또는 LDAP 항목에 URI 값을 추가할 수 있게 해주는 보조 클래스labeledURIObject를 정의했습니다.
  • 인코딩되지 않은 공백 하나가 URI와 선택적 사람용 레이블을 구분했지만, 여러 값이 서로 다른 관련 자원을 의미할 수도 있고 하나의 자원에 대한 서로 다른 위치를 의미할 수도 있었습니다. 이 형식은 관계 유형을 전혀 제공하지 않았습니다.
  • 저장된 URI가 도달 가능성, 최신성, 권위 또는 동등성에 대한 증표는 아니었습니다. 레이블도 신뢰할 수 있는 마크업이 아니었습니다. RFC 2079는 레이블을 HTML에 그대로 붙여 넣는 행위를 명시적으로 경고했습니다.

1997년 1월, 디렉터리에 웹 주소를 넣는 일에서 어려운 부분은 클릭 가능한 링크를 만드는 것이 아니었습니다. 이미 여러 독립 그룹이 LDAP과 X.500에서 URL을 실험하고 있었습니다. 더 어려운 문제는 서로 다른 클라이언트들이 인식할 수 있도록 그 실험들에 하나의 속성 이름과 하나의 값 형식을 부여하는 것이었습니다.

RFC 2079는 이 속성을labeledURI라고 명명했습니다. 대소문자를 구분했고 같은 항목에 여러 번 나타날 수 있었습니다. 각 값은 URI로 시작했습니다. 당시에는 RFC 1738에 따른 URL이었으며, 이어서 공백과 사용자 친화적인 레이블이 올 수 있었습니다. URL 안에 리터럴 공백은 허용되지 않았기 때문에, 첫 번째 인코딩되지 않은 공백이 깔끔한 경계를 이루었습니다. 클라이언트는 주소가 어디서 끝나고 표시 문구가 어디서 시작하는지 추측할 필요가 없었습니다.

이것은 분명한 조율 성과였습니다. 동시에 매우 좁은 성과이기도 했습니다.

다중성은 질문을 그대로 남겨두었다

이 메모는 여러 값이 일반적으로 X.500 객체와 관련된 서로 다른 자원들을 가리키지만, 대신 동일한 자원의 서로 다른 위치를 가리킬 수도 있다고 말합니다. 이 둘은 운영상 전혀 다른 주장입니다. 직원 프로필은 홈페이지와 사진을 연결할 수 있습니다. 서비스 항목은 기본 사이트와 미러를 나열할 수 있습니다. 출판물은 HTML 보기와 FTP 사본을 가질 수 있습니다. 그러나 이 속성에는초상,미러,정본,아카이브,대체 경로를 나타내는 기계 판독 가능한 단어가 없었습니다.

레이블은 종류나 크기를 암시할 수 있었지만, RFC 2079는 레이블에 대한 문법을 정의하지 않았습니다. "현재 서비스"는 검증된 관계가 아니라 작성자가 제공하는 산문에 불과했습니다. 디렉터리는 어떤 값이 알려진 속성 아래에서 항목에 부착되었다는 사실은 증명할 수 있었습니다. 그러나 작성자가 왜 그 값을 부착했는지, 대상이 이에 동의하는지, 두 값이 서로 대체 관계인지는 증명할 수 없었습니다.

이 구분은 문자열이 다를 때 더 날카로워집니다. RFC 3986은 이후 URI 비교를 사다리처럼 단계적으로 설명했습니다. 문자가 정확히 같으면 동등하다고 결론지을 수 있지만, 다른 문자열도 구문별 또는 스킴별 정규화 이후에는 동일한 자원을 가리킬 수 있습니다. 따라서 대소문자가 정확히 일치하는 디렉터리 값은 쓰여진 그대로를 보존할 뿐, 동일성에 관한 모든 질문을 해결해주지는 않습니다.

객체 클래스는 가용성을 넓혔을 뿐 권위를 넓히지는 않았다

RFC 2079는top에서 파생된 보조 클래스labeledURIObject도 정의했습니다. 이 클래스는 아무것도 요구하지 않으면서labeledURI를 허용했습니다. 관리자는 객체의 주 클래스를 재설계하는 대신 기존 객체에 이 클래스를 추가할 수 있었습니다. 다른 클래스들이 이 속성을 직접 포함할 수도 있었습니다.

이후 문서들은 두 경로를 모두 보여주었습니다. RFC 2798은inetOrgPerson에서labeledURI를 선택 사항으로 만들고 개인 홈페이지의 예를 들었습니다. RFC 3383은 이 속성과 보조 클래스를 LDAP의 디스크립터 표에 등재했습니다. 이러한 기록들은 정의를 재사용 가능하고 찾아볼 수 있게 만들었습니다. 그러나 어떤 값 뒤의 페이지를 확인하거나, 채택률을 측정하거나, 개인의 레이블을 조직의 보증으로 바꾸지는 않았습니다.

RFC 3296은 이후 LDAP 하위 참조를 위해 동일한 값 형식을 차용하면서 특정 용도를 부과했습니다. 그ref속성은 레이블을 무시하고, 리퍼럴을 구성할 때 레이블을 제거하며, 다중 값 속성의 모든 URI를 사용하고, 참조 무결성 검증을 보유 서버에 권장하지 않았습니다. 이 더 좁은 프로토콜은 일반 형식 자체가 완전한 관계가 아니었던 이유를 보여줍니다. 값이 무엇을 하는지는 별도의 문서가 말해야 했습니다.

친화적인 텍스트는 실행 경계였다

레이블은 사람이 소비하기 위한 것이었습니다. RFC 2079는 당시 클라이언트들이 비ASCII 문자를 일관되게 처리하지 못할 수 있어 비ASCII 문자 사용을 권장하지 않았으며, X.500 문자 규약과 HTML 이스케이프를 구분했습니다. 더 중요하게는, 보안 절에서 프로그램이 레이블을 HTML에 무작정 붙여 넣어서는 안 된다고 경고했습니다. 악의적인 레이블은 주변 문서의 독자를 오도하는 태그를 포함할 수 있었습니다.

이 경고는 저장과 렌더링을 분리합니다. 디렉터리는 정확한 레이블을 반환할 수 있습니다. 그러나 이스케이프 처리, 레이아웃, 링크 목적지 공개, 무엇을 클릭 가능하게 만들지에 대한 결정은 여전히 클라이언트의 몫입니다. 그 다음 대상이 또 다른 경계를 만듭니다. 리디렉션, 콘텐츠 변경, 만료된 호스트, 스킴 동작은 저장된 항목 밖에서 일어납니다.

따라서 안전한 증거 사슬은 값보다 깁니다. 먼저 디렉터리 항목과 속성 값을 확인합니다. URI와 레이블을 파싱합니다. 의미를 추측하지 않고 다중성을 기록합니다. 누가 값을 공급했으며 어떤 관계를 주장하는지 파악합니다. 적절한 정책에 따라 대상을 검색합니다. 그런 다음 출처, 최신성, 동등성, 안전한 표시를 각각 별도로 확립합니다.

하나의 속성은 두 이름을 대체했을 뿐 두 의미를 대체하지 않았다

이전 초안은labeledURL을 정의했었습니다. RFC 2079는 작업 그룹이 URI와 URL을 위한 별개의 속성보다 하나의 URI 속성을 선호했기 때문에 이를 폐기(deprecated)했습니다. 전환 경로가 필요한 클라이언트를 위해 구식 정의는 그대로 두었습니다.

통합은 속성 이름의 수를 줄였습니다. 그러나 배포된 레거시 값을 지우지도, 마이그레이션이 실제로 이루어졌음을 증명하지도, 관계 어휘를 추가하지도 않았습니다. 더 넓은 단어 URI라고 해서 모든 스킴이 서로 교환 가능해진 것도 아니었습니다. 더 작은 공유 표면의 대가는, 응용 프로그램이 실제로 필요로 하는 구분들을 여전히 스스로 보존해야 한다는 것이었습니다.

RFC 2079의 오래 남는 교훈은 절제되고 정확합니다. 포인터가 어떻게 부착되는지 표준화하면 교환이 가능해집니다. 그러나 그 포인터가 왜 중요한지, 여전히 작동하는지, 그곁의 단어에 사람이 얼마나 신뢰를 두어야 하는지는 표준화하지 않습니다.

출처