요약

  • RFC 3368은go:에 서로 다른 두 가지 역할을 부여했습니다. 특정 CNRP 서비스를 지목하거나, 클라이언트가 선택한 서비스에 일반 이름 질의를 전달하는 것입니다.
  • 서버 고정형id=링크는 독자가 그 링크가 가리킨다고 믿는 사람의 이름을 담지 않은 채 레코드를 가리킬 수 있었습니다. 문법, 등록, 해석은 서로 별개의 근거였습니다.

2002년 8월, RFC 3368은 평범한 웹 주소로는 깔끔하게 풀리지 않는 문제를 위한 링크를 제안했습니다. 사람들은 이름을 기억하지만, 네트워크는 식별자와 서비스를 통해 자원을 이동시킵니다.go:스킴은 이름 자체를 권위 있는 것으로 만들지 않았습니다. 이 스킴은 클라이언트가 CNRP 질의를 서비스 쪽으로 전달하는 방식을 정의했을 뿐입니다.

구분은 콜론 뒤에 오는 문자에 있습니다.go://cnrp.example?Ada%20Lovelace는 특정 서버를 지명하고 그 서버에 질의를 전달합니다.go:Ada%20Lovelace는 서버를 빼놓으며, RFC는 이 형태를 클라이언트가 이미 구성해 둔 하나 이상의 CNRP 서비스에 사용하도록 의도했습니다. 따라서 같은 눈에 보이는 이름이 서로 다른 기기에서 서로 다른 서비스 집합으로 흘러들 수 있었습니다. 링크 안에 보편적인 리졸버 목록이 담겨 있지는 않았습니다.

RFC 3368은 서버만 있는 URI에도 다른 의미를 부여했습니다. 특정 조회가 아니라 CNRP 서비스를 식별한다는 것입니다. 클라이언트는 프로토콜의servicequery를 통해 그 서비스의 기능을 물어볼 수 있었습니다. 서버가 비어 있으면 로컬 호스트를 의미했고, 다른 전송 계층 정보가 없으면 기본값으로 1096 포트의 HTTP가 지정되었습니다. 이러한 기본값은 클라이언트가 대화를 시작하도록 돕는 것이었습니다. 서버가 도달 가능하고, 신뢰할 수 있고, 아직 운영 중이라는 것을 입증하지는 않았습니다.

스킴의 간결함은 의도된 것이었습니다. CNRP 요청에는 XML 표현이 있었지만, 복잡한 질의를 그대로 넣으면 URI가 다루기 힘들어질 것입니다. RFC 3368은 일반 이름과 속성/값 쌍을 위한 더 작은 문법을 정의했습니다. UTF-8 인코딩과 문법 밖 문자에 대한 퍼센트 이스케이프를 요구했으며, 예제에서는ü를 UTF-8 바이트로 인코딩했습니다. RFC의 짧은 형식들은 예제일 뿐이었고, ABNF가 권위 있는 문법이었습니다.

더 중요한 경계 사례는go://cnrp.example?id=5432345였습니다. 이 URI는 일반 이름을 담지 않은 채 특정 서버의 특정 레코드를 가리켰습니다. RFC 3368의 보안 절은 이 불일치를 지적했습니다. 누군가 링크가 “BMW”에 현재 매핑된 자원을 가리킨다고 생각할 수 있지만, URI에는 “BMW”라는 이름이 없다는 것입니다. 기계가 읽을 수 있는 식별자는 안정적일 수 있지만, 그것을 신뢰하라는 사람에게는 여전히 불투명할 수 있습니다.

동반 프로토콜인 RFC 3367은 서비스 제공자의 발견과 선택, 등록, 소유권, 고유성을 초기 범위 밖에 두었습니다. 따라서 RFC 3368의 클라이언트 구성 서비스 집합은 누가 이름을 대변하는가에 대한 전역적 답이 아니라 로컬 선택으로 남았습니다. 이후 IANA URI 스킴 레지스트리는go를 Permanent로, RFC 3368을 참조 문서로 등재했습니다. 그 기록은 등록 상태를 증명할 뿐, 브라우저 지원, 활성 서비스, 트래픽, 채택을 증명하지 않습니다.

이것이 유용한 역사적 경계입니다. 링크는 서비스, 질의, 레코드를 각각 식별할 수 있지만, 이 셋은 서로 교환 가능한 것이 아닙니다. Lu Heng의 “Reality Layers”와 “Running-Code Primacy”는 문법, 등록된 설계, 관찰된 운영을 분리해 두기 위한 공개된 편집 관점이며, 프로토콜 요구사항이 아니고go:가 배포되었다는 증거도 아닙니다.

출처