요약

  • LOC는 좌표 자체와 별개로 개체 크기, 수평 불확실성, 수직 불확실성을 따로 유지했다. 작은 개체가 부정확하게 알려진 위치를 가질 수도 있었다.
  • 기본 수평 정밀도는 그 길이의 반경이 아니라 지름 10,000미터의 원이었다. 정밀한 좌표 인코딩이 그 한정을 무효화하지 않았다.
  • 네트워크 위치 폴백은 호스트 자체를 찾지 않고도 호스트 질의에 근사한 답을 줄 수 있었다. 캐시 신선도와 DNSSEC 서명은 없는 측량 일자를 대신 제공하지 않았다.

핀 바깥의 원

좌표에는 많은 자릿수가 있다. 마커에는 뾰족한 끝이 있다. 그러나 어느 쪽도 그 장소가 얼마나 잘 알려져 있는지 독자에게 알려주지 않는다.

1996년 1월에 발표된 실험적RFC 1876은 그다지 편리하지 않은 이 정보를 위한 공간을 마련했다. 그 LOC 자원 레코드는 호스트, 네트워크, 서브넷의 지리적 위치를 기술했다. 위도, 경도, 고도와 함께, 기술되는 개체의 크기와 별도의 수평·수직 정밀도 값을 담았다.

텍스트 형식에서 수평 정밀도가 생략되면 10,000미터가 되었다. 이는 오차 원의 지름이지 10킬로미터 반경이 아니었다. 같은 레코드는 1미터라는 기본 개체 크기를 사용할 수 있었다. 넓은 불확실성 영역 안의 작은 개체는 완전히 일관된 기술이었다.

좌표만 추출하는 응용 프로그램은 그 기술을 겉보기에 더 강한 무언가로 바꿀 수 있었다. 자릿수를 바꿀 필요도 없었다. 원을 생략하기만 하면 되었다.

이것은 그 표현 경계에 대한 역사이며, LOC가 범용 지리위치 시스템이 되었다는 주장이 아니다. 형식은 소비자가 나중에 버리는 구분을 보존할 수 있다. 레코드를 이해한다는 것은 그 출력을 지상의 한 지점으로 취급하기 전에 그 구분들을 되찾는 일이다.

이름 근처에서 유지된 지리

문제의 일부는 행정적이었다. 일부 사이트의 지리 정보는 UUCP 지도를 통해 유통되었다. 중앙화된 유지·검증은 그 기술들을 최신 상태로 유지하기 어렵게 만들었다. DNS는 다른 방식을 제공했다. 어떤 이름의 책임자는 그 위치 정보를 로컬에서 유지하고, 다른 사람들은 분산 시스템을 통해 그것을 질의할 수 있었다.

그보다 앞선 실험적RFC 1712(1994년 11월)는 그러한 로컬 유지 야말로 바탕에 두고 GPOS 레코드를 제안했다. 이 문서는 SNMP의 sysLocation(에이전트와 접근 맥락, 흔히 로컬 기술을 동반)과 당시 배포가 제한적이던 X.500을 포함한 대안들을 검토했다. 이것들은 오늘날 어느 시스템에 대한 조사가 아니라 역사적 설계 고려사항이다.

GPOS는 지리적 구성 요소에 세 개의 인쇄 가능한 숫자 문자열을 사용했다. 이는 세 개의 이진 IEEE 부동소수점 값이 아니었다. 소수점 아래 많은 자릿수를 인쇄할 수 있다는 점은 상세한 서술을 가능하게 했지만, 누군가 실제로 그 정밀도까지 위치를 측정했다는 뜻은 아니었다.

DNS는 주장을 게시하고 검색할 장소를 제공했다. 이름에 대한 권한이 측량의 정확성에 대한 권한이 되지는 않았다. LOC가 그 주장을 더 명시적으로 한정하는 방법을 제공하기 전에도 이 구분은 이미 존재했다.

축의 라벨도 데이터였다

GPOS를 신중히 읽어야 할 또 하나의 이유가 있다. 이 문서는 경도와 위도 용어와 정의를 서로 바꿔 쓰고 있다. 2006년에 보고된 공식정오표 541은 문제를 지적하고 수치 순서는 유지한 채 수정된 라벨을 제안한다.

그 정오표는 “Verified”가 아니라 “Held for Document Update”로 표시되어 있다. 이는 원래 명세가 이미 공식적으로 개정되었거나 모든 구현이 모호성을 동일하게 해소했다는 증거가 아니다. 기존 좌표 예시를 조용히 고쳐 신뢰할 수 있는 설정 레시피처럼 재현해서는 안 된다.

이는 단지 숫자가 너무 부정확하다는 문제가 아니었다. 잘못된 축에 배정된 숫자는 완벽하게 읽히면서도 잘못된 의미를 가질 수 있다. 공유된 구문만큼 공유된 해석도 중요했다.

LOC의 등장을 GPOS의 공식 은퇴로 읽어서도 안 된다. RFC 1876은 RFC 1712를 obsolete하지 않는다.IANA DNS 파라미터 레지스트리는 여전히 GPOS를 타입 27로, LOC를 타입 29로 나열한다. 등록은 형식을 구분할 뿐, 설치 수를 세거나 유지 품질을 확정하거나 채택률을 측정하지 않는다.

하나 이상의 스케일을 담은 16옥텟

LOC 버전 0의 RDATA는 16옥텟이다. 이는 타입별 데이터이지, 자원 레코드 전체나 DNS 메시지 전체가 아니다. 버전, 크기, 수평 정밀도, 수직 정밀도는 각각 1옥텟이다. 위도, 경도, 고도는 각각 4옥텟이다.

위도와 경도는 오프셋 정수를 사용해 각초의 1/1,000 단위로 표현된다. 2의 31제곱은 적도 또는 본초 자오선을 나타내며, 그보다 큰 값은 북쪽 또는 동쪽을 의미한다. 이들은 2의 보수 필드에 복사된 보통의 부호 있는 각도 값이 아니다.

이 인코딩의 분해능은 프로그램이 인접한 어떤 숫자들을 구분할 수 있는지를 말해줄 뿐이다. 게시자가 대응하는 물리적 위치들을 실제로 구분할 수 있는지에 대해서는 아무 말도 하지 않는다. 경도의 경우, 각도 차이가 나타내는 지상 거리는 위도에도 의존한다. 모든 곳에서 통하는 단일한 미터 환산 상수는 존재하지 않는다.

크기와 정밀도는 다른 압축 방식을 사용한다. 십진 기수 자릿수와 십진 지수 자릿수로 센티미터 값을 만든다. 두 니블은 0부터 9까지의 값을 정의하며, 10부터 15까지가 아니다. 0 곱하기 10의 0제곱은 정확한 오차 0이 아니라 1센티미터 미만을 뜻한다. 기수가 0이고 지수가 0이 아닌 조합은 정의되지 않았다.

따라서 이 레코드는 표현에 대해 의도적인 한계를 두었다. 무제한의 의미 있는 자릿수를 제공하지 않았다. 구현은 익숙하지 않은 버전이 같은 해석을 유지한다고 가정하는 대신 버전을 확인해야 했다. 바이트를 수신하는 데 성공하는 것은 그것을 읽는 일의 시작에 불과했다.

크기는 확실성의 동의어가 아니었다

SIZE는 개체를 감싸는 구의 지름이다. 수평 정밀도는 수평 오차 원의 지름이다. 수직 정밀도는 가능한 수직 오차의 총합이다. 이 중 하나를 근거 없는 플러스-마이너스 값으로 다루면 기술되는 범위 자체가 변한다.

반폭 해석이 적절한 경우에는 전체 범위를 절반으로 나누어야 한다. 그것이 통계적 신뢰 수준을 추가할 근거가 되지는 않는다. RFC는 명시된 비율의 관측이 원 안에 들어온다고 말하지 않는다. 소비자는 그런 보장을 만들어서는 안 된다.

개체 크기와 불확실성의 구분이 특히 유용하다. 1미터짜리 개체는 광범위한 우편 지역 수준으로만 알려져 있을 수 있다. 반대로 큰 개체가 잘 알려진 기준 중심을 가질 수도 있다. 물리적 분포와 좌표의 품질은 서로 다른 질문에 답한다.

존 파일 형식에서 크기와 두 정밀도 값은 선택 사항이다. 기본값은 각각 1미터, 10,000미터, 10미터이다. RFC 1876은 이 기본값들을 우편번호에서 얻을 수 있는 근사 지리 정보의 가용성에 연결한다. 생략된 텍스트 값들은 이러한 기본값을 통해 버전 0의 와이어 데이터에도 여전히 표현된다.

그 텍스트 형식에서 고도, 크기, 정밀도는 미터 단위로 쓰이지만, 대응하는 이진 필드는 센티미터를 사용한다. 두 형식 사이를 오갈 때는 단위 경계를 존중해야 한다. 해석 없이 받은 맨 숫자는 모든 문자를 보존하더라도 의미를 잃을 수 있다. 스프레드시트나 지도가 그런 경우다.

고도에는 부호가 아니라 기준이 필요했다

LOC의 고도는 WGS84 기준 타원체를 참조한다. 저장된 값은 그 기준보다 100,000미터 아래인 기저에서부터 센티미터를 센다. 따라서 타원체 기준 0미터는 인코딩된 값 10,000,000센티미터에 해당한다.

이 오프셋 덕분에 기준면 아래의 위치도 음의 저장 정수 없이 표현할 수 있다. 그렇다고 사이트의 실제 높이에 100킬로미터를 더하는 것은 아니다. 평균 해수면을 기준 타원체와 동일하게 만들지도 않는다.

RFC는 적절히 고도나 수직 정밀도를 조정하는 조건으로 해수면 근사를 허용한다. 중요한 역사적 요점은 기준면이 명시적으로 유지되어야 한다는 것이다. 소수 자릿수가 늘어난다고 잘못된 기준면에서 출발한 문제를 만회할 수는 없다.

이러한 한정들 덕분에 데이터는 높이가 붙은 핀만큼 즉각적으로 단정하지 않다. 그러나 더 많은 정보를 준다. 좌표는 특정한 표현 안에서 이루어진 서술이지, 스스로 설명되는 물리적 사실이 아니다.

호스트 질문이 네트워크 답이 될 수 있었다

LOC는 응용 프로그램이 위치를 찾는 방법도 한정했다. 이름에서 시작할 때, 먼저 그 이름의 LOC를 확인하고 보통의 방식대로 CNAME을 따라야 했다. 직접적인 LOC가 없다면, 연관된 A 레코드가 네트워크나 서브넷 위치로 가는 경로를 제공할 수 있었다.

IPv4 주소에서 시작할 때는 먼저 IN-ADDR.ARPA를 통해 이름을 얻은 뒤 그 이름의 LOC를 확인했다. 이는 뒤집힌 주소 이름 바로 아래에 LOC를 놓으라는 일괄 지시가 아니었다. 직접 결과가 없을 때, 선택적 네트워크 폴백이 남아 있었다.

그 폴백은 1989년 4월에 발표된RFC 1101의 역사적 네트워크 이름짓기 메커니즘을 응용한 것이었다. 특수한 역방향 이름, PTR 레코드, A 레코드 모양의 서브넷 마스크 데이터가 네트워크와 서브넷 이름을 되찾는 데 도움을 주었다. 그 맥락에서 관련된 A 모양의 값은 마스크이지, 수신 대기 중인 서비스의 주소가 아니었다.

LOC 절차는 이름들을 모아 더 구체적인 서브넷에서 넓은 네트워크 쪽으로 거슬러 올라가며 처음 발견되는 위치를 사용했다. 이는 DNS의 보통 부모 라벨 순회도, BGP의 최장 접두사 포워딩도 아니었다. 그 시기의 클래스 기반 IPv4 가정을 유지했다. RFC 1876은 다른 주소 방식으로의 적용 가능성을 논의했지만 일반적인 IPv6 확장은 정의하지 않았다.

목표는 정밀한 위치를 얻을 수 없을 때 더 크고 덜 정밀한 영역을 표시하는 것이었다. 폴백 레코드는 여전히 네트워크나 서브넷을 기술했다. 그것을 한 호스트의 측정된 위치로 제시하면 서술의 주체가 조용히 바뀐다.

여러 A 주소는 또 하나의 응용 프로그램 선택을 만들었다. 연관된 폴백 위치 중 임의의 것, 일부, 또는 전부를 사용하거나 결합할 수 있었다. 멀티홈드 호스트의 직접 LOC는 그 모호성을 줄일 수 있었다. 형식은 성공적인 검색마다 유일하게 정당화되는 핀 하나를 보장하지 않았다.

신선한 답이 오래된 주장을 실을 수 있었다

RFC 1035의 자원 레코드 프레임워크는 소유자 이름, 타입, 클래스, TTL, 데이터를 포함한다. TTL은 원본을 다시 조회하기 전까지의 캐시 수명을 결정한다. 그것은 위치가 물리적으로 얼마나 오래전에 측정되었는지를 말하지 않는다.

2005년 3월의 후속 문서RFC 4033은 캐시 일관성과 DNSSEC 서명의 유효 기간을 구분한다. DNSSEC는 데이터 출처 인증과 무결성을 제공할 뿐, 지리적 검사를 제공하지 않는다. 기밀성도 제공하지 않는다.

추론은 좁지만 중요하다. 진실하게 게시된 좌표조차 오래되었거나, 잘못 설정되었거나, 잘못된 범위로 해석될 수 있다. 새 서명이 측량 일자를 추가하거나 잘못된 고도 기준을 고쳐주지는 않는다. 버전 0 LOC에는 그런 질문에 답할 별도의 계기 기술이나 측정 타임스탬프가 없다.

제안된 시각적 트레이서우트나 관리 지도 용도도 이 한계 안에서 읽어야 한다. IP 홉에 등록된 좌표는 패킷의 실제 물리적 경로의 증거가 아니다. 형식 제안은 배포 실태 조사가 아니며, 이 역사는 현재의 지리위치 정확성에 대해 어떤 주장도 하지 않는다.

공개 여부는 정확성과 별개의 문제였다. GPOS는 DNS 정보를 공개적인 것으로 명시적으로 다루었고, LOC는 정밀한 지리가 물리적 보안 위험을 높일 수 있다고 경고했다. 이 경고들은 설계 고려사항을 확립할 뿐, 특정 공격의 증거가 아니다. 장소를 정확하게 기술할 수 있다는 사실이 그 정확성을 게시하는 것이 적절한지를 결정해주지는 않았다.