요약

  • RFC 3937은urn:iptc를 등록하고 IPTC 산하에 할당을 중앙화했으며, 승인된 표준, 초안, 작업 문서를 위한 별도의 하위 분기들을 두었다.
  • IPTC는 지속성과 접근성을 유지할 것을 약속했지만, RFC는 URL 리졸버를 나중에 개발할 것이라고 밝혔고 별도의 검증 메커니즘은 규정하지 않았다. 견고한 이름 자체가 접근을 보장하지는 않았다.

레지스트리가 먼저 왔다

2004년 10월,RFC 3937은 공식 네임스페이스 식별자iptc의 등록을 요청했다. International Press Telecommunications Council(IPTC)는 뉴스 산업이 사용하는 DTD, XML 스키마, XML 네임스페이스, 스타일시트, PDF, 사무 문서 및 기타 자료에 대해 안정적인 이름이 필요했다. 파일은 이동할 수 있고 웹 위치는 바뀔 수 있었다. 그런 변화를 견뎌내도록 설계된 식별자는 단순히 당시의 또 하나의 URL일 수는 없었다.

RFC 편집자 기록은 이 메모를 Informational로 분류한다.정오표 기록은 이후의 정정 사항을 확인하는 창구다. IANAURN 네임스페이스 레지스트리는 현재iptc를 RFC 3937과 함께 나열하고 있다. 이 사실들은 등록된 네임스페이스와 그 문서적 권위를 확립한다. 그러나 모든 하위 문자열이 할당되었거나, 모든 자원이 계속 이용 가능했거나, 2004년에 리졸버가 운영 중이었다는 것을 입증하지는 않는다.

이러한 구분은 이미 URN 아키텍처의 일부였다.RFC 1737은 지속적인 이름을 위한 기능적 요구사항을 기술했다.RFC 2141은 URN 문법을 규정했다.RFC 2276은 리졸루션을 아키텍처적 문제로 다루었고,RFC 3401은 일부 리졸루션 응용이 사용하는 Dynamic Delegation Discovery System을 설명했다.RFC 3406은 RFC 3937이 따른 네임스페이스 정의 메커니즘을 제공했다. 문법, 등록, 리졸루션은 인접한 층이었지 동의어가 아니었다.

하나의 소유자가 고유성을 통제했다

RFC 3937은 네임스페이스 특정 문자열(NSS)을 세 개의 최상위 분기로 나누었다.std는 승인된 IPTC 표준을 규정하거나 설명하는 자원을 담았다.std-draft는 공식 승인 전의 유사한 자원을 담았다.workdoc은 승인된 표준에 직접 관련되지는 않지만 IPTC의 작업과 관련된 문서를 담았다.

이 계층 구조는 통제 구조를 담고 있었다. IPTC 관리이사가 고유성을 강제했고, 할당은 네임스페이스 소유자와 그 권한 기관으로 제한되었다. IANA는iptc를 등록했지만 그 아래의 모든urn:iptc:...를 승인하지는 않았다. 따라서 문법적으로 올바른 문자열이 IPTC가 그것을 할당했다는 증거가 되지는 못했다.

이것은 중앙화된 기관의 장부였다. 그 강점은 충돌 통제였다. 하나의 권위 기관이 두 자원이 같은 이름을 받는 일을 막을 수 있었다. 그 의존성 역시 분명했다. 고유성과 출처 추적은 IPTC의 연속성, 기록, 절차에 의존했다. 네임스페이스 등록은 하위 URN을 할당 이벤트에 암호학적으로 묶지 않았다.

RFC 3085는 이미 NewsML 자원을 위한 URN 네임스페이스를 만들었었다. RFC 3937은 IPTC가 NewsML을 넘어선 표준과 회원 외부에서 사용되는 문서를 위해 더 넓은 계층 구조가 필요하다고 설명했다. 새 네임스페이스는 범위를 확장했다. 그 자체로 오래된 NewsML 이름이 모두 이전되었거나 하나의 레지스트리가 이전의 모든 식별자를 대체했다는 것을 증명하지는 않았다.

current는 이름으로서는 안정적이지만 대상으로서는 이동 가능했다

std와std-draft분기에는 표준 이름과 표준 버전이 포함되었다. 명시적 버전의 경우 경로는 특정 판, 그리고 선택적으로 특정 자원 버전을 식별할 수 있었다. 그러나 RFC 3937은 또한 값current가 표준의 현재 버전에 해당하는 자원을 가리키도록 허용했다.

이 단어는 두 종류의 지속성을 드러낸다.current를 포함하는 문자열은 그것이 가리키는 버전이 바뀌더라도 그대로 유지될 수 있다. 이것은 불변의 판이 아니라 지속적인 별칭이다. 재현성이 필요한 소비자는 명시적 버전을 필요로 한다. 최신 승인 자료를 원하는 소비자는 이동하는 별칭을 선호할 수 있다. 두 이름 모두 정당할 수 있지만 서로 다른 질문에 답한다.

예시들은 이 계층 구조를 구체적으로 보여 주었다. NewsML DTD, 초안 상태의 NITF XML 스키마, SportsML XML 네임스페이스, 지침 문서, 그리고 하나의 작업 문서가 그것이다. RFC 3937은 예시가 대표적이며 실제 자원을 가리키지 않을 수 있다고 경고했다. 예시를 데이터베이스에 복사하는 것은 할당이 존재한다는 증거가 아니다.

이후의 IPTCCore XMP 스키마 명세는 명시적인urn:iptc:std:...문서 URN을 담고 있다. 이것은 최소한 하나의 구체적인 이후 사용 사례에 대한 1차 증거다. 그러나 네임스페이스의 전수 조사도, 리졸버 테스트도, 출판 이후 끊김 없는 접근의 증명도 아니다. IPTC의네임스페이스 문서는 다른 IPTC 네임스페이스 표면에 대한 현재의 웹 표현을 보여 준다. 현재의 도달 가능성을 과거의 연속적 역사로 역산할 수는 없다.

지속성은 약속이었고, 리졸루션은 미래의 작업이었다

RFC 3937은 IPTC가 IPTC URN으로 식별되는 모든 자원의 접근성과 지속성을 유지할 것을 약속한다고 밝혔다. 그리고 IPTC가 모든 할당된 URN을 웹 리졸루션을 위한 URL에 매핑하는 적절한 메커니즘을 개발할 것이라고 명시했다. 검증 부분에서는 별도의 메커니즘이 규정되지 않았으며, 미래의 리졸버가 URN의 유효성 여부도 보여 주게 될 것이라고 했다.

미래 시제가 이 역사의 중심이다. 조직은 접근 메커니즘이 명세에 존재하기 전에 권위를 등록하고 관리를 약속했다. 이 순서가 반드시 결함은 아니다. 네임스페이스는 리졸버가 배치되기 전에 할당될 수 있고, 지속적인 이름은 그것을 해석하는 방법을 이미 아는 문서와 시스템 안에서 유용할 수 있다. 그러나 주장은 한계를 유지해야 한다.

URN은 식별한다. 리졸버는 매핑한다. URL은 위치를 찾는다. 서버는 표현을 제공한다. 검증 절차는 할당 권위 기관이 실제로 그 이름을 발행했는지 답한다. 한 단계의 실패가 다른 모든 단계를 지우지는 않는다. 유효한 URN이 일시적으로 리졸브되지 않을 수 있다. 리졸버는 죽은 URL을 반환할 수 있다. 도달 가능한 URL이 잘못된 버전을 제공할 수 있다. 올바른 문법이지만 할당되지 않은 문자열이 문법 파서를 통과할 수 있다.

RFC 8141은 이후 일반 URN 문법과 의미론을 갱신했다. 이는 현대 프레임워크를 이해하는 데 도움을 주지만, RFC 3937이 약속한 리졸버가 2004년에 존재했거나 이후의 운영 행동이 연속적이었다는 증거로 사용될 수는 없다.

Lu Heng의 글들 —최소 초기 명세와 이후의 자발적 채택,실행 코드 우선주의— 는 이 기록을 위한 편집적 규율을 제공한다. 출판, 할당, 구현, 배치, 사용은 별개의 사건이다. RFC 3937은 견고한 명명 약속과 거버넌스 표면을 확립했다. 이후 단계들을 입증할 수 있는 것은 오직 리졸버 로그, 레지스트리 내보내기, 아카이브 점검, 자원 검색뿐이다.

가장 날카로운 교훈은 리졸버가 연기되었다고 해서 URN이 실패했다는 것이 아니다. 지속성은 결코 문자열 하나에만 속하지 않았다는 것이다. 그것은 할당을 보존하는 기관, 매핑을 유지하는 운영 서비스, 버전을 보관하는 저장소, 그리고 고정된 판과 그날의current중 무엇을 원하는지 물어보는 클라이언트에 의존했다. 이름은 연속성을 약속할 수 있었다. 그 약속을 이행하려면 등록 시점에 아직 존재하지 않던 시스템들이 필요했다.