요약

  • RFC 3939는Caller-ID와Caller-Name헤더를 만들어, 저장된 음성 메시지에 대해 전화 시스템이 표시한 내용을 보존하되 그 값을 인증된 신원으로 만들지는 않았습니다.
  • 문서 자체의 실패 사례는 전송이 곧 이식성이 아니었던 이유를 보여 줍니다. 내선 번호는 전달 이후 쓸모없어지고 오히려 정보를 노출할 수 있었고, 잘린 국제 번호는 엉뚱한 사람에게 걸리는 그럴듯한 콜백을 만들어 낼 수 있었습니다.

번호가 담길 자리가 필요했다

전화가 걸려 왔지만 아무도 받지 못했고, 발신자는 음성 메시지를 남겼습니다. 전화망은 번호와, 어쩌면 표시 이름을 알고 있었습니다. 녹음을 담게 될 인터넷 메일 저장소는 메일함 주소 지정 방법은 알지만 발신자의 이메일 주소는 모를 수 있었습니다. 2004년 12월 Standards Track으로 발표된RFC 3939가 다루던 문제가 바로 이 불일치였습니다.

기존의 선택지들은 모두 평범한From필드를 왜곡했습니다. 시스템은 표시 이름 안에 전화번호를 넣거나, 자릿수를 조합해 임의의 주소를 만들거나, 발신자가 알려지지 않았다고 선언할 수 있었습니다.RFC 3801, 즉 Voice Profile for Internet Mail은 이미 인터넷 메일 회신을 받을 수 없는 전화 응답 메시지를 위한 특수한non-mail-user발신자를 인식하고 있었습니다. 따라서 RFC 3939는 전화망의 표시 데이터에 고유한 자리를 마련했습니다. 번호는Caller-ID, 이름은Caller-Name으로요.

이 분리가 유용했던 이유는 출처가 중요했기 때문입니다. 메일의From필드는 인터넷 메일 시스템 안에서 메시지 발신자를 기술했습니다. 새 헤더들은 전화 시스템이 착신자에게 제공했던 내용을 기록했습니다. 두 신원을 조정하지도 않았고, 전화 표시를 증거로 바꾸지도 않았습니다.

헤더는 경로가 아니라 자릿수를 보존했다

Caller-ID문법은 의도적으로 단초했습니다. 하나 이상의 숫자 뒤에 선택적으로NumberingPlan매개변수가 올 수 있습니다. 하이픈, 공백, 그리고 많은 국제 표기에서 쓰이는 선행+마저 제외되었습니다. 내부 전화의 경우 기업은 내선 번호만 기록할 수 있었습니다. 국제 전화의 경우 RFC는 국가 코드, 국내 목적지 코드, 가입자 번호를 포함한 최대 15자리의 전체 E.164 수열을 요구했습니다.

결정적인 한정자는 선택 사항이었습니다.NumberingPlan이 없으면 기본 의미는unknown이었습니다.local은 그 번호가 메시지를 저장한 음성 메일 시스템의 도메인 내부에서 이해되는 계획에 속한다는 뜻이었습니다.e164는 국제 구조를 선언했습니다. 따라서 같은 자릿수가 주변의 작은 메타데이터 조각에 따라 매우 다른 운영상 가치를 지닐 수 있었습니다.

RFC 3939는 자신의 경계를 명확히 했습니다. 이 문서는 전화 시스템으로부터 받은 번호를 변경 없이, 해석 없이 저장하려고 했습니다. 주소 지정 가능하거나 발신 가능한 전화번호를 정의하지는 않았습니다. 그 작업은 다른 사양들이 담당했습니다.RFC 2806은 같은 로컬 자릿수가 지역마다 다른 의미를 가질 수 있으므로 로컬 전화 URL에 맥락을 요구했습니다.RFC 3191은 전역 E.164 형식의 번호를 인터넷 메일 주소 안에 부호화하고 그 형식을 위해 선행+를 예약했습니다. 이런 더 풍부한 형식들이 무엇을 담아 두었는지가, 벌거벗은 포획 문자열이 무엇을 담지 않았는지를 보여 줍니다.

그렇게 설계는 하나의 관찰을 보존했습니다. 메시지가 저장될 때 표시되었던 자릿수라는 것입니다. 미래의 행동에 필요한 모든 사실을 보존하지는 않았습니다. 콜백에는 발신 맥락, 현재의 라우팅, 통화를 걸 권한, 그 결과도 필요합니다. 어느 것도 헤더만으로 따라오지 않습니다.

전달은 보이지 않는 경계를 깨뜨렸다

가장 많은 것을 드러내던 사례는 잘못된 문법이 아니었습니다. 유효한 로컬 내선이 자신이 유효했던 장소를 벗어난 경우였습니다. 회사 안에서4087은 충분할 수 있었습니다. 착신 메시지가 외부 수신자에게 전달되면 그 네 자릿수는 더 이상 도달 가능한 목적지를 식별할 수 없었습니다. 더 나쁘게도 전달된 헤더는 회사의 내부 발신 계획 일부를 노출할 수 있었습니다.

값은 완벽하게 살아 남았습니다. 의미는 그렇지 않았습니다. 이는 인터넷에서 반복되는 실패 모드입니다. 시스템은 손실 없는 전송을 칭찬하면서, 해석을 제공하던 관리 경계를 간과합니다. 메시지 봉투는 내부 번호 계획보다 훨씬 쉽게 도메인을 넘을 수 있었습니다.

국제 사례는 그럴듯해 보일 수 있다는 점에서 더 위험했습니다. RFC 3939는 일부 시스템이 번호를 10자리로 잘라낸다고 경고했습니다. 예시는 아일랜드 번호로 시작했고, 선행 자릿수가 제거된 나머지는 북미 번호와 비슷하게 보였습니다. 수신자는 명백한 오류를 보지 못할 수 있었습니다. 인터페이스는 무관하고 당연히 짜증 낸 사람에게 걸리는 콜백을 제안할 수 있었습니다.

이것은 단순한 데이터 누락이 아니었습니다. 잘림은 하나의 의미를 또 다른 그럴듯한 의미로 바꾸었습니다. "10자리가 있다"만 확인하는 검증 규칙은 그 오염을 오히려 통과시켜 주었을 것입니다.

이름 역시 표시 데이터였다

Caller-Name에는 자신만의 이식성 문제가 있었습니다. 전화 신호 처리는 여러 문자 집합을 제공할 수 있었습니다. RFC 3939는 ASCII를 기본 표현으로 사용하고, 7비트 ASCII로 부족할 때는 RFC 2047인코딩으로 원래 문자 집합을 허용했습니다. 같은 부호화 옵션이 없는 수신 시스템은 잘못된 이름을 표시할 수 있었습니다. 공급자는 전달하는 내용을 줄일 수도 있었습니다. 헤더가 50자까지 허용했는데 어떤 경우에는 15자로도 말입니다.

그 어떤 장치도 인간을 인증하지 않았습니다. 발신자 이름은 전화망이 제공한 정보로, 그 신호 처리와 공급자 정책, 표시 한계에 의해 제한된 것이었습니다. RFC의 보안 절은 제한된 정보를 그에 맞게 다루었습니다. 헤더에는 공급자 간 숨겨진 세부 사항이 아니라Private Name처럼 착신자가 보았을 내용이 담겨야 했습니다.

그러나 이메일로의 이동은 두 번째 프라이버시 표면을 만들었습니다. 전화번호가 이제 메시지 헤더 안에 놓이고, 전달과 함께 이동하며, 메일 클라이언트가 표시하기를 선택하기 전까지는 보이지 않은 채 남을 수 있었습니다. 착신자가 전화 화면에서 번호를 보는 것이 허용되었을지 모르지만, 그렇다고 모든 이후 수신자가 그 값의 출처나 민감성을 이해한다는 뜻은 아니었습니다.

시간조차 단일하지 않았습니다. 전화 시스템이 날짜와 시간을 제공했다면 구현은 그것을 평범한Date헤더에 넣거나, 대신 로컬 시스템 시간을 사용할 수 있었습니다. 따라서 저장된 타임스탬프는 통화의 정확한 시각으로 취급되기 전에 출처를 확인받아야 했습니다.

RFC 3939의 역사적 중요성은 이 소박한 설계에 있습니다. 새 헤더가 네트워크들이 신원이나 맥락, 행동에 대해 합의하도록 만들 수 있다는 착각 없이, 전화 표시 데이터를 어디에 저장할지 해결했습니다. 번호는 인터넷 메일로 넘어갔습니다. 그러나 내부 번호 계획, 문자 재생산, 공개 기대, 그리고 성공한 콜백을 증명하는 데 필요한 증거는 자동으로 함께 넘어가지 않았습니다.