요약

  • RFC 3305는 URL과 URN을 URI 공간의 서로 배타적인 영역으로 다루던 방식에서 벗어나, 스킴을 확장 가능한 단위로 보는 관점으로의 전환을 기술했습니다. “URL”은 별개의 형식적 상자가 아니라 유용한 설명으로 남을 수 있다는 것이었습니다.
  • 2002년 이 보고서는 구현을 강제하는 지시가 아니라 Informational(정보 제공) 문서였습니다. 이후 RFC 3986이 이를 인용하면서 향후 사양에서 “URI”를 사용하도록 권고했습니다. 이는 수용의 흔적이지, 유일한 원인이나 보편적 준수의 증거는 아닙니다.

더 이상 도움이 되지 않던 분류 체계

초기 웹에서 이 레이블들은 분류 규칙처럼 보였습니다. Uniform Resource Locator는 어떻게 자원에 도달하는지를 밝혀 자원을 가리켰고, Uniform Resource Name은 위치와 무관하게 자원을 식별하는 것으로 기대되었습니다. 고전적 정의에서 URI는 둘 중 하나였습니다. 이 구분은 가르치기에 충분히 직관적이었지만, 사양들이 “URL 스킴”, “URI 스킴”, “URN 스킴”을 마치 서로 다른 계층을 가리키는 것처럼 사용하면서 곤란해졌습니다.

RFC 3305는 이 혼선을 정리하려는 시도의 기록입니다. W3C는 2000년 10월 Uniform Resource Identifier에 관한 후속 작업을 검토하기 위한 기획 그룹을 구성했고, 여기에는 W3C 회원과 초청된 IETF 전문가가 참여했습니다. 2002년 8월 보고서는 고전적 분할과 이른바 현대적 관점을 대조했습니다. 즉 스킴은 일반적으로 URI 스킴이며, 하나의 스킴이 자체적인 하위 공간을 정의할 수 있다는 것입니다.http:는 URI 스킴이었고,urn:역시 그 아래 네임스페이스를 둔 URI 스킴이었습니다.

이 관점에서 “URL”은 모든 스킴이 반드시 들어가야 하는 형식적 구획을 가리키지 않았습니다. URL은 접근 메커니즘이 자원의 위치를 찾는 데 도움을 주는 URI에 대한 유용한 비공식 설명으로 남았습니다. 이 전환은 미묘하지만 결과가 컸습니다. 스킴이 본질적으로 로케이터인지 이름인지 묻는 대신, 특정 식별자와 그 할당 주체가 무엇을 하게 만드는지 물을 수 있게 된 것입니다. 하나의 스킴은 이름 부여, 위치 지정 또는 둘 다를 지원할 수 있었습니다.

이것은 문서상의 마찰에 대한 대응이었지, 세계 곳곳의 사용자가 같은 방식으로 혼란스러워했다는 주장이 아니었습니다. RFC 3305는 RFC 2396의 일반 URI 구문, RFC 2717의 “URL 스킴” 등록 절차 등 이전 사양들의 뒤섞인 용어를 지적했습니다. 인접 표준이 같은 종류의 확장을 서로 다른 이름으로 부르면, 작성자와 구현자, 레지스트리 관리자는 확장의 실질을 논하기 전에 먼저 번역 작업을 떠안게 됩니다.

권고는 명령이 아니었다

이 보고서는 W3C/IETF 공동 모델, RFC 2717과 RFC 2718을 개정하여 URI 스킴을 다루도록 하는 것, 대안 등록 트리에 대한 더 명확한 규칙, 공개·폐기·보류 스킴에 관한 더 나은 IANA 정보를 제안했습니다. 또한 2002년 당시의 레지스트리 상태를 기록했습니다. 공식 목록의 34개 스킴과 10개의 형식적 URN 네임스페이스 식별자라는 수치는 해당 메모에서의 스냅샷이지 현재 총계가 아닙니다.

문서의 지위가 중요합니다. RFC 3305는 Informational이었습니다. 인터넷 커뮤니티에 보내는 보고서이지 Standards Track 프로토콜이 아니었고, W3C 프로젝트나 IETF 작성자, 스킴 소유자에게 코드나 용어를 바꾸도록 강제할 수 있는 표결도 아니었습니다. 이 문서는 조율 문제를 명명하고 그에 대한 경로를 제시했습니다. 운영상의 통제는 스킴을 정의하는 사양들, 스킴을 등록하는 사람들, IANA가 관리하는 목록, 식별자를 파싱하거나 할당하는 구현자들 사이에 분산된 채 남았습니다.

3년 뒤RFC 3986은 이 용어가 실제로 전파되었음을 보여 주는 강력한 문서적 증거를 남겼습니다. URI, URL, URN을 다루는 절에서 RFC 3986은 URL이 기본 접근 메커니즘을 제공하는 URI의 하위 집합이라고 말합니다. 또한 스킴이 반드시 이름이거나 로케이터일 필요는 없으며, 향후 사양에서는 더 제한적인 “URL”과 “URN” 대신 일반 용어 “URI”를 사용하도록 권고하면서 RFC 3305를 명시적으로 인용합니다. 이는 이후 Standards Track 문서에서 이루어진 직접적인 수용입니다. 그러나 이것이 이전 메모가 단독으로 그 선택을 낳았다는 것, 모든 표준 작성자가 이를 따랐다는 것, 혹은 일상어 “URL”이 사라졌다는 것을 보여 주지는 않습니다.

등록 이야기는 관련되되 별개의 트랙에서 이어졌습니다.RFC 7595는 이후 URI 스킴 가이드라인과 등록 절차에 관한 Best Current Practice를 문서화했습니다.RFC 8820은 또 다른 방향에서 스킴 권한을 다시 다뤘습니다. 스킴이 자신의 URI 구조를 정의하며, 하위 구조를 지시하는 외부 표준은 문제를 일으킬 수 있다는 것입니다. 이 후속 문서들은 어휘만으로는 소유권, 구문, 등록 문제를 해결할 수 없는 이유를 함께 보여 줍니다.

기록이 말할 수 있는 것과 없는 것

RFC 3305는 표준사 역사의 작은 조각으로 읽는 것이 가장 적절합니다. 공동 기획 그룹이 용어 충돌을 확인하고 언어와 레지스트리 작업을 제안했으며, 변화는 이후의 사양과 참여자들에게 맡겼습니다. RFC 3986의 명시적 인용 덕분에 우리는 하나의 권고가 더 형식적인 문서로 흘러든 과정을 따라갈 수 있습니다. 다만 기록은 이 변화가 어느 정도의 혼란을 제거했는지 정량화하지 않고, 보편적 수용을 입증하지도 않으며, 현대적 URI 처리의 공로를 RFC 3305에 독점적으로 돌리지도 않습니다.

이 절제가 바로 메커니즘의 일부입니다. 조율 메모는 그 해답을 강제할 권한 없이도 공통 문제를 가시적으로 만들 수 있습니다. 발행은 다른 이들이 채택할 수 있는 참조물을 만들 뿐이며, 실제로 무엇이 바뀌는지는 이후의 사양, 레지스트리 절차, 구현이 결정합니다.