요약

  • RFC 3017은 로밍 전화번호부를 접속 지점(POP)을 선택하고 전화 접속, DNS, 프록시, 게이트웨이, 사용자 이름 설정을 구성할 수 있을 만큼 기계 판독 가능하게 만들었지만, 업데이트·전송 프로토콜은 명시적으로 정의하지 않았다.
  • 단조 증가하는 번호부 및 항목 카운터는 알려진 범위 안에서의 차이를 알릴 수는 있었다. 그러나 누가 데이터를 발행했는지, 어떤 대상군 변형이 적용되는지, 클라이언트가 이를 확정했는지, 목록에 기재된 접속 서비스가 여전히 작동하는지는 증명하지 못했다.

여행자에게는 두 개의 파일이 있었다. 하나는 버전 41, 다른 하나는 버전 73이라고 적혀 있었다. 문제가 단순한 산술이라면 선택은 자명했다.

그러나 두 파일이 반드시 같은 번호부를 설명하는 것은 아니었다. 로밍 컨소시엄은 사용자 그룹별로 서로 다른 버전을 준비할 수 있었다. 고객은 그다음 국가별 또는 무선 전용 부분 집합을 추출할 수 있었다. 번호부 이름은 임의의 문자열이었고, 표준은 그 이름 안에 전역 발행자 식별 정보를 제공하지 않았다. 73이 41보다 크다는 것은 사실이지만, 이 사람, 이 여정, 이 구성 계보에 대해 자동으로 더 최신이라는 뜻은 아니었다.

바로 이 구분이 2000년 12월에 발표된 RFC 3017,XML DTD for Roaming Access Phone Book의 핵심에 있다. 이 문서는 단순한 전화번호 목록 이상을 표준화했다. 그 XML은 소프트웨어가 어느 네트워크 접속 지점을 선택할지, 선택 후에 호스트를 어떻게 구성할지 알려줄 수 있었다. 미디어 유형, 최소·최대 속도, 터널링 프로토콜, 다이얼 스크립트, 요금 정보, DNS 및 메일 서버, 웹·FTP 프록시, 기본 게이트웨이, 지원 연락처, 사용자 이름 앞뒤에 추가할 문자열까지 담을 수 있었다.

이것은 익숙한 이름 "전화번호부"를 달고 있는 제어 번들이었다.

컨소시엄은 보편적 실체가 아니라 하나의 뷰를 편집했다

정보 경로는 네트워크 사업자에서 시작되었다. 회원들은 자신의 서비스와 접속 서버에 대한 설명을 로밍 컨소시엄에 제출했다. 컨소시엄은 그 기여물을 고객용 통합 번호부로 조립했다. RFC 3017은 차등 제공을 전제로 했다. 그룹은 자신의 필요에 맞게 조정된 번호부를 받을 수 있었고, 사용자는 그로부터 더 작은 부분 집합을 파생할 수 있었다.

이 아키텍처는 이식성을 가능하게 했다. 동시에 출처 경계도 만들었다. 하나의 POP 항목은 사업자의 진술로 시작해, 컨소시엄의 편집을 거쳐, 대상군별 판본에 등장한 뒤, 사용자가 추출한 부분 집합 속에 남을 수 있었다. 각 단계는 XML 유효성은 유지하면서 완전성, 순서, 주변 참조, 업데이트 계보를 바꿀 수 있었다.

RFC 2194는 이미 이 운영적 배경을 문서화하고 있었다. 검토된 한 로밍 시스템에서 회원들은 사업자 및 POP 정보를 사무국에 보냈고, 사무국은 수작업으로 이용 가능한 번호를 편집해 FTP, 웹, 클라이언트 메커니즘을 통해 업데이트를 배포했다. 번호부에는 위치, 프록시, 다이얼러 구성, 지원 연락처, 서버 설정이 담길 수 있었다. 이 역사가 RFC 3017의 배포를 증명하는 것은 아니다. 다만 여러 조직이 이미 분산된 진술을 여행자가 소비하는 구성으로 바꾸고 있었다는 점, 즉 공통 포맷이 왜 중요했는지를 보여준다.

DTD는 그 문제의 한 부분을 해결했다. 모든 당사자에게 공통 문법을 제공한 것이다. 모든 판본이 세계에 대한 같은 뷰가 되도록 만들지는 않았다.

카운터는 자신의 범위가 확인된 뒤에야 변화를 설명했다

최상위phoneBook@version은 번호부가 바뀔 때마다 증가해야 하는 단조 증가 정수였다. 서버는 클라이언트의 숫자와 자신의 현재 숫자를 비교해 어떤 조치가 필요한지 판단할 수 있었다. RFC는 서버가 차이를 담은 파일의 URL을 반환할 수 있다는 예를 들었다.

그러나 그 텍스트는 그 차이 파일을 정의하지 않았다. 요청, 전송, 인증 교환, 원자적 커밋, 롤백, 복구 절차도 정의하지 않았다. 실제로 서문은 번호부 업데이트·전송 프로토콜을 명시적으로 제외했다.

따라서 그 숫자가 갖는 의미는 좁았다. 서버는 "이 이름의 번호부가 클라이언트의 것과 다르다고 믿는가?"에는 답할 수 있었다. 그러나 그 자체로 다음 질문에는 답할 수 없었다:

  • 어느 발행자가 이 카운터 이름 공간을 소유하는가?
  • 이것이 전체 번호부인가, 대상군별 판본인가?
  • 로컬에서 파생된 부분 집합이 다시 번호가 매겨졌는가?
  • 제안된 차이 파일은 어느 기저 버전을 전제하는가?
  • 클라이언트가 모든 바이트를 받았는가?
  • 구 번호부가 교체되기 전에 검증이 끝났는가?
  • 새 구성이 활성화되었는가?
  • 더 새로운 편집이 낡은 POP을 바로잡았는가, 아니면 단지 브랜딩 문구를 바꿨는가?

더 큰 정수는 시계가 아니었다. 서명도, 커밋 영수증도 아니었다.

RFC 2477은 이 구분을 이례적으로 명확하게 만든다. 그 번호부 업데이트 프로토콜 기준은 서버 진위성, 임의의 이전 버전에서 최신 버전으로의 이동, 업데이트 적용 전 무결성 검사, 결과 번호부의 검증, 경량 전송, 언어·문자 집합 선택을 요구했다. 이 요구들이 존재한 이유는 정확히 포맷 카운터가 그것들을 수행할 수 없기 때문이다.

항목 카운터 주위에는 완전한 병합 계약이 없었다

각pop은entryVersion을 가졌고, 이 역시 단조 증가하며 번호부 병합이나 업데이트에 유용할 수 있다고 설명되었다. 그러나 POP 요소 자체에는 XMLID가 없었다. 셋업, 지원, 사업자 컨테이너에는 ID가 있어 문서 내에서 참조될 수 있었지만, 접속 지점은 주소, 미디어, 기타 내용으로 기술될 뿐이었다.

상태 변화의 형태를 다룰 때 이것이 중요해진다. 카운터는 인식된 대상이 바뀌었다고 말할 수 있지만, 주변 시스템은 여전히 어느 대상이 인식되는지 알아야 한다. 전화 주소가 바뀌면, 그 결과는 수정된 POP인가, 교체된 POP인가, 아니면 두 개의 POP인가? 항목이 사라졌다면, 그것은 의도적 삭제인가, 이 대상군 부분 집합에서의 제외인가, 부분 전송에서의 일시 부재인가, 편집 과정의 손실인가? RFC 3017은 톰스톤이나 충돌 규칙을 정의하지 않았다. 그럴 의도도 없었다.

그것은 DTD 밖에 있는 업데이트 프로토콜의 문제였다. 운영상의 오류는entryVersion의 존재로부터 완전한 병합 알고리즘을 추론하는 데서 온다.

같은 절제는 확장성에도 적용된다. RFC는 고정된 구조부와 분리된 확장 가능한 매개변수 엔티티 선언 집합을 두고 IANA 등록 정책을 제안했다. 새 정보 요소는 이전 문서가 여전히 유효하도록 선택적이어야 했다. 그러나 구 문서의 유효성을 유지하는 것이, 구 다이얼러가 새 문서의 모든 새 값을 이해한다는 뜻은 아니다. 호환성에는 파서, 지원되는 확장 집합, 알 수 없거나 사용할 수 없는 데이터에 대한 로컬 정책이 필요했다.

검증은 형태를 확인했지, 텍스트 뒤의 네트워크는 확인하지 않았다

XML DTD는 번호부의 운영 값을 위한 강타입을 제공하지 않았다. 대부분의 내용은#PCDATA였다. RFC 3017은 FQDN, IP 주소, 인코딩된 이미지 같은 의도된 유형에 대한 notation을 추가했지만, notation이 DNS 서버를 조회하거나 모뎀을 접속하거나 요금제를 검증하거나 게이트웨이의 도달 가능성을 확인하지는 않았다.

문서는 완벽하게 well-formed이면서도 이미 퇴역한 전화번호를 담을 수 있었다. 목록된 프록시가 여행자를 거부하면서도 검증을 통과할 수 있었다. 로컬 구현에 없는 터널 프로토콜을 지명할 수도 있었다. 최소 속도는 그 통화에서 관측된 속도가 아니라 능력치를 설명할 수 있었다. 요금 문구는 문법상 존재하면서 상업적으로 낡았을 수 있었다.

이 격차는 클라이언트가 그 필드들에 따라 행동할 수 있었기 때문에 더 무거워졌다.dialScript요소는 POP에 접속하기 위한 스크립트를 담았다. 셋업은 DNS, 메일, 프록시 서버나 기본 게이트웨이를 제공할 수 있었다. 지능형 다이얼러는 사용자 이름 접두사·접미사를 자동으로 결합할 수 있었다. 따라서 낡은 항목은 단지 그릇된 라벨이 아니었다. 통화를 연결하고, 신원 문자열을 바꾸고, 이후 애플리케이션 트래픽을 라우팅할 수 있었다.

"전화번호부"라는 표현은 이 아티팩트를 서술적인 것처럼 들리게 했다. 그러나 그 행동은 실행 가능할 수 있었다.

서명은 진술을 보호했지, 그 진실의 지속은 보호하지 않았다

RFC 3017의 보안 장은 발행자의 신뢰할 수 있는 인증과 배포되는 번호부 정보의 무결성 보호를 요구했다. 그 기능들을 DTD 밖에 두고, 하나의 가능한 메커니즘으로 PGP 서명을 제안했다.

이 구분은 옳았다. XML 유효성과 발행자 인증은 별개의 검사다. 다만 두 검사를 각자가 지지하는 것보다 강한 결론으로 다시 결합해서는 안 된다.

외부 서명은 검증된 바이트가 특정 키와 서명 정책 아래 인증된 바이트와 동일함을 확립할 수 있다. 그러나 그것은 번호부의 모든 번호에 전화를 걸지 않는다. 서명 이후 POP이 철회되었는지 사업자에게 묻지 않는다. 서명된 판본이 이 고객 그룹을 위한 것인지 증명하지 않는다. 클라이언트가 구 기저 버전과 섞지 않고 파일을 확정했는지 보여주지도 않는다.

마찬가지로 업데이트 서버의 인증이 이후 접속 세션을 증명하지는 않는다. RFC 2486은 Network Access Identifier를 PPP 인증 경로에 두고, realm과 유사한 형식을 인증 요청 라우팅에 활용했다. 그 일은 선택과 전화 접속 이후에 일어났다. 정확한 POP 번호도 신원을 거부하는 NAS로 이어질 수 있었다. 물리 링크의 성공도 여전히 인가 실패로 끝날 수 있었다. 로그인의 성공도 사용할 수 없는 주소 할당, DNS, 프록시, 터널 상태로 이어질 수 있었다.

근거 사슬에 여러 영수증이 있었던 이유는, 그 운영 자체에 여러 단계가 있었기 때문이다.

구성은 둘 이상의 권위로부터 도착할 수 있었다

Setup 요소는 사업자나 POP에 따라 달라질 수 있는 값을 기술했다. RFC 3017은 그 일부가 DHCP 같은 다른 경로로도 제공될 수 있음을 인정했다.

그로 인해 DTD가 답하지 않은 실용적 질문이 생겼다. 번호부가 한 DNS 서버를 말하고 DHCP가 다른 서버를 제공한다면, 어느 쪽이 권위를 가지는가? 답은 클라이언트, 사업자, 접속 방식, 보안 정책, 시점에 따라 달라질 수 있었다. 포맷은 하나의 진술을 표현할 수 있었지만, 작동 중인 네트워크는 또 다른 값을 공급하고 있었다.

이것은 설계의 결함을 보여주는 근거가 아니다. 구성 소유권이 직렬화 문법의 밖에 살아 있다는 근거다. 운영자는 각 값을 어느 계층이 만들었는지, 어느 쪽이 이겼는지, 호스트가 실제로 무엇을 사용했는지 기록해야 했다.

"버전 73 번호부 설치됨"이라는 장애 티켓은 지나치게 거칠다. 유용한 기록에는 발행자와 번호부 이름, 대상군 변형, 전체 다이제스트, 선택된 POP과 항목 버전, 서명 결과, 파서와 확장 집합, 다운로드 기저 버전, 커밋 결과, 활성 구성 다이제스트, 다이얼 결과, PPP 상태, 인증 결과, 주소 할당, 터널 상태, DNS 및 프록시 관측, 애플리케이션 도달 가능성이 포함되어야 했다.

그래야만 조사자가 낡은 항목, 잘못된 병합, 실패한 다이얼, 거부된 신원, 서비스 장애를 구분할 수 있었다.

이 역사는 범위가 정해진 표준화의 교훈이다

RFC 3017은 하나의 DTD가 로밍 시스템 전체를 작동시킬 수 있다고 주장하지 않았다. 이식 가능한 공통 형태가 필요한 부분을 표준화하고, 자신이 표준화하지 않은 주변 책임들을 명명했다. 그 절제는 이 문서에 현대적 업데이트 체계가 없었다는 소급적 불평보다 더 가치 있다.

실수는 나중에, 구현이나 감사에서 좁은 아티팩트를 보편적 증명처럼 취급할 때 온다.

Lu Heng의 Running-Code Primacy는 유용한 렌즈 하나를 제공한다. 공개된 구성은 네트워크를 만나야 운영적 사실이 된다는 것이다. 그의 Reality Layers 렌즈는 문서 형태, 인증된 발행자, 설치된 상태, 성공한 서비스가 하나의 라벨로 무너지지 않도록 지킨다. Minimum Initial Specification은 공통 포맷이 왜 얇게 남을 수 있는지, 동시에 전환 규칙, 호환성 라벨, 로컬 검증, 관측 가능한 채택이 왜 여전히 명시적 자리를 필요로 하는지를 설명한다.

이것들은 분석적 렌즈이지, 저자들의 동기에 대한 주장이 아니다.

여행자에게는 전화번호부가 필요했다. 이식 가능한 목록이 없다면, 많은 사업자에 걸친 로밍은 수작업적이고 취약했다. 그러나 맨 위에 인쇄된 그 숫자는 신선도의 모든 무게를 짊어질 수 없었다.

그것은 번호부가 바뀌었다고 말했을 뿐이다. 네트워크는 여전히 스스로 답해야 했다.

출처