요약

  • RFC 2345는 기업의 웹 정보를 찾는 일을 DNS 관리나 이름에 대한 권리 판단과 분리했다. 그 실험적 서비스는 추정상의 기업명을 받아 URL/기업명 쌍을 돌려주었다.
  • 매칭, 철자 변형, 표시되는 '기업명'의 의미조차 각 서버에 맡겨졌다. 따라서 프로토콜 적합성이 결과의 올바름을 입증하지는 못했다.
  • 데모는 매치의 순위 매기기와 절단, 단일 결과의 자동 열기, 하나의 유한한 데이터베이스에서 나온 '찾을 수 없음'을 지원했다. 그 어느 것도 완전성이나 권위를 증명하지 않았다.
  • 도메인 등록, DNS 위임, 페이지 통제, 인증서, 법인 신원, 서비스 성과는 각각 별개의 근거 층으로 남았다.
  • 영구적인 교훈은 단순함이 실패했다는 것이 아니다. 단순한 위치 지정자를 신원 자격 증명이나 서비스 영수증으로 끌어올려서는 안 된다는 것이다.

결과 카드는 실제보다 더 완전해 보였다

답 하나가 들어 있는 브라우저 창을 상상해 보라. 기업명은 익숙하다. URL은 그럴듯해 보인다. 경쟁하는 행도, 경고도, 점수도 없다. 다음 클릭은 거의 행정 절차처럼 느껴진다. 기계가 그 기업을 찾아낸 것이다.

RFC 2345는 거의 그런 경험을 만들기 위해 설계되었다. 클라이언트는 상업적으로 제공되는 WHOIS 서버에 기업명을 보냈다. 서버는 한 줄 이상을 돌려보냈고, 각 줄은 URL과 이어서 '기업명'이라 불리는 표시 문자열로 이루어졌다. 매치가 하나뿐이면 즉시 가져올 수 있었고, 여러 개면 사용자가 고르는 목록으로 표시될 수 있었다.

그 편의는 1990년대 후반의 실제 문제를 해결했다. 'XYZ Company'는 분명www.xyz.com에 있을 것이라는 추측은 정보 탐색의 짐을 DNS 네이밍 관행에 얹었다. 또한 세 가지 서로 다른 분쟁 — 도메인이 어떻게 관리되는가, 누가 이름에 권리를 갖는가, 평소 이름을 아는 주체의 웹 정보를 사람이 어떻게 찾는가 — 을 뒤섞었다. RFC 2345는 세 번째 문제를 앞의 두 문제에서 의도적으로 분리했다.

프로토콜의 절제는 타당했다. 오류는 좁은 답을 메모가 분리한 질문들을 해결한 것처럼 읽는 순간 시작된다.

매치를 결정한 것은 프로토콜이 아니라 서버였다

요청에는 법인 식별자, 관할권, 등록 번호, 인증된 주장이 담기지 않았다. 담긴 것은 추정상의 기업명이었다.

RFC 2345는 그 입력의 의미를 서버에 맡겼다. 각 공급자는 어떤 철자, 약어, 변형을 받아들일지 스스로 결정할 수 있었다. 명세는 더 나아갔다. 매치 판단이 올바른지 여부는 그 범위 밖이었다. 대소문자 구분 없는 처리가 하나의 기계적 관행을 제공했지만, 이는 주체 해석을 정의하지 않았다.

이것이 중요한 이유는 이름이 키가 아니기 때문이다. 짧은 상호는 여러 나라의 서로 무관한 사업체에 속할 수 있다. 모회사, 자회사, 제품이 같은 브랜드를 공유할 수 있다. 기업은 익숙한 공개 명칭을 유지한 채 법적 이름을 바꿨을 수 있다. 음역은 여러 라틴 철자를 낳을 수 있다. 구두점과 법인 접미사가 사라져도 남은 단어가 고유해지지는 않는다.

규격을 준수하는 서버는 이런 긴장을 신중하게 다룰 수도, 엉망으로 다룰 수도 있었다. 적합성은 교환이 합의된 라인 형식을 사용했음을 보여줄 뿐, 공급자의 정규화 규칙, 원본 기록, 충돌 처리, 편집 판단을 인증하지 않았다.

'기업명'은 표시 필드였지 법적 신원이 아니었다

응답은 구조화되어 보였다. 모든 줄이 눈에 보이는 두 부분으로 이루어졌기 때문이다. 첫 번째는 URL이었다. 줄의 나머지는 기업명이라 불렸다.

그러나 RFC 2345는 그 두 번째 부분의 의미를 표준화하지 않기로 의도적으로 정했다. 그것은 단순한 이름일 수도, 위치나 업종을 덧붙인 것일 수도, 서버가 고른 다른 설명일 수도 있었다. 이 필드는 사람이 URL을 고르도록 돕기 위해 존재했지, 인증된 법인 신원을 담기 위한 것이 아니었다.

그 설계는 클라이언트가 수행해야 하는 해석의 양을 줄였다. 동시에 이용자가 라벨 뒤에 어떤 근거가 있는지 추론할 수 없음을 의미했다. 그 줄에는 법적 레지스트리, 회사 번호, 관할권, 출처 시점, 편집자, 신뢰도 점수, 정정 이력, 명명된 주체와 도메인 사이의 관계를 담는 표준 위치가 없었다.

이 부재는 우연한 버그가 아니었다. 그것은 실험의 미니멀리즘이 지불한 대가였다.

URL은 자원을 가리켰을 뿐 소유권을 담지 않았다

RFC 1738은 URL을 인터넷 자원을 찾아 접근하기 위한 간결한 표현으로 기술했다. 그 기능만으로도 충분히 유용했다. RFC 2345는 그런 위치 지정자를 사람이 읽을 수 있는 기업 문자열 옆에 놓았다.

어떤 문서도 URL을 소유권 증서로 만들지 않았다.

도메인은 명명된 기업, 모회사, 자회사, 대행사, 호스팅 공급자, 유통사 또는 무관한 제3자가 등록했을 수 있다. 페이지는 공식적일 수도, 과거의 것일 수도, 위임된 것일 수도, 침해되었을 수도, 리디렉션되었을 수 있다. 편집 검토 시점에 올바른 연관이었더라도 나중에 바뀔 수 있다.

RFC 1738은 URL이 계속 같은 대상을 가리킨다는 일반적 보장이 없음을 명시적으로 경고했다. RFC 2345는 추가 위험을 짚었다. 번역 서버가 스푸핑되면 기업에 대해 잘못된 URL을 돌려줄 수 있다는 것이다. 제안된 방어는 인증서, 서명, 기타 진위 신호에 대한 주의였지, 매핑 라인에 대한 신뢰가 아니었다.

따라서 그 줄은 한정된 주장만 지지했다. 이 디렉터리가 이 시점에 이 표시 라벨에 대해 이 위치를 제공했다는 것. 도메인 등록, 위임, 페이지 통제는 각각 자체적인 근거를 필요로 했다.

단일 결과는 과도한 확신을 불러일 수 있었다

제안된 클라이언트 동작은 매치가 여럿일 때 모호성을 드러냈다. 이름들을 보여주고 사용자가 고르게 할 수 있었다. 단일 결과는 다르게 다뤄졌다. 클라이언트는 확인을 요청하거나, 사용자가 직접 입력한 것처럼 URL을 가져올 수 있었다.

데모 클라이언트는 더 빠른 분기를 택했다. 데이터베이스 매치가 하나뿐임을 발견하면, 추가 사용자 개입 없이 기본 브라우저를 실행해 그곳으로 이동했다.

'단 하나'는 고유성처럼 들렸다. 그것은 하나의 공급자의 데이터, 매칭 규칙, 현재 검색 아래에서 매치가 하나뿐이라는 뜻이었다. 다른 디렉터리에는 다른 항목이 있을 수 있었다. 철자 변형이 기록을 놓쳤을 수 있었다. 정당한 기업이 부재했을 수 있었다. 두 법인이 정규화로 병합되었을 수 있었다. 상위 결과는 단지 순위 매기기와 절단 과정의 생존자였을 수도 있다.

자동 이동은 디렉터리의 판단을 사용자 행동으로 바꿔버렸다. 그 판단이 틀린 것은 아니지만, 그 범위를 숨기는 비용을 올렸다.

10개 라인이 전수 디렉터리를 만들지는 않았다

데모 서버는 Dun & Bradstreet가 공급한 약 20만 9천 개의 항목을 담고 있었다. 10개 이상의 기록이 매치되면 상위 10개만 돌려보냈다. 클라이언트는 점수 순으로 정렬된 2개에서 10개 사이의 이름을 표시했다.

이 세부 사항은 세 가지 서로 다른 한계를 드러낸다.

첫째, 데이터베이스는 유한했다. '찾을 수 없음'은 제출된 문자열이 그 데이터베이스의 어떤 것과도 매치되지 않았다는 뜻이었다. 기업이 존재하지 않거나, 웹사이트가 없거나, 다른 곳에서 찾을 수 없다는 뜻이 아니었다.

둘째, 순위가 작용했다. 프로토콜은 점수, 그 특징, 그 해석을 표준화하지 않았다. 높은 순위는 공급자의 판단이었지, 기업–도메인 관계의 중립적 속성이 아니었다.

셋째, 절단은 성공적인 답을 설계상 불완전하게 만들었다. 돌려받은 10개 라인은 클라이언트가 결코 보지 못한 추가 매치와 공존할 수 있었다.

데모는 추가나 변경을 위한 경로도 제공하지 않았고 정확성에 대한 책임을 부인했다. 이것들은 주변적 단서가 아니었다. RFC에 문서화된 유일한 구체적 구현의 유지보수 경계를 기술한 것이었다.

디렉터리 품질은 전송 형식 바깥에 있었다

RFC 2345는 중심 한계를 분명히 밝혔다. 결과 품질은 기반이 되는 디렉터리, 그리고 그것을 구축하는 데 쓰인 편집·조사 작업에 달려 있다는 것. 어느 쪽도 프로토콜의 문제가 아니었다.

전송 형식은 완벽하게 구현되면서도 디렉터리는 낡았을 수 있다. 파서는 편집자가 연관을 검증했는지 모른 채 URL을 라벨에서 분리할 수 있다. 서버는 오래된 오류를 그대로 보존한 채 캐시에서 빠르게 답할 수 있다. 클라이언트는 기록의 출처와 시점을 감춘 채 모든 문자를 올바르게 렌더링할 수 있다.

그래서 전송의 올바름과 정보의 올바름은 별개의 영수증이 필요하다. 전자에는 질의, 응답 바이트, 변형 번호, 파싱 결과를 담을 수 있다. 후자에는 출처, 유효 시점, 출처 비교, 주체 해석 규칙, 변경 이력, 정정 경로가 필요하다.

RFC 2345는 첫 번째 층을 표준화했다. 두 번째 층은 의도적으로 공급자와 시장 압력에 맡겼다.

공급자 선택이 답의 틀을 바꿨다

이 메모는 하나의 공급자나 공급자 레지스트리에 대한 기술적 필요를 보지 못했다. 클라이언트가 서버 선택을 허용하리라 기대했다.

그 다원성은 유용했다. 경쟁하는 디렉터리들은 서로 다른 출처, 시장, 언어, 편집 방식을 시도할 수 있었다. 그러나 공급자 선택이 근거의 일부가 되었다. 어느 서버도 프로토콜을 위반하지 않은 채, 같은 입력이 서로 다른 후보 집합, 순위, '찾을 수 없음' 결과를 낳을 수 있었다.

따라서 응답은 서비스의 신원 없이는 평가될 수 없었다. 공급자, 질의 시점, 정확한 입력이 빠진 캡처된 결과는 보기보다 약했다. 다른 서버에 대해 재실행하는 것은 단순한 중복 확인이 아니었다. 그것은 별개의 편집 체계를 시험하는 것이었다.

시장은 저자들이 바랐듯이 더 나은 매핑에 보상할 수 있었다. 하나의 응답을 살펴보는 사용자는 경쟁이 이미 신뢰할 만한 승자를 뽑았다고 추론할 수 없었다.

페이지를 찾는 일은 여전히 서비스 증명에 앞서 있었다

매핑이 정확하고 페이지가 실제로 명명된 기업에 속한다고 가정해 보라. 사용자의 실질적 과제는 여전히 끝나지 않았다.

DNS가 해석되어야 했다. 네트워크 경로가 작동해야 했다. 서버가 응답해야 했다. TLS 근거는 호스트명과 의존하는 맥락에 맞아야 했다. 리디렉션은 수용 가능한 통제 사슬 안에 남아 있어야 했다. 페이지는 기대하는 제품, 지원 또는 정보를 제공해야 했다. 거래가 실패할 수도 있었다. 지원 대기가 방치될 수도 있었다. 세련된 웹사이트가 사용자 지역에서 이용 불가한 서비스를 기술하고 있을 수도 있었다.

RFC 2345는 그 어떤 결과도 약속하지 않았다. 그 클라이언트는 사이트로 이동할 수 있었지만, 방문이 신뢰할 만한 서비스를 낳았다는 것을 인증할 수 없었다.

이 마지막 구분은 웹 탐색이 발견과 사용을 하나의 동작으로 연결하기 때문에 놓치기 쉽다. 근거는 그 둘을 분리해 두어야 한다. 디렉터리 결과, 도메인 통제 기록, 인증된 페이지, 완료된 서비스 거래는 서로 다른 네 가지 영수증이다.