요약

  • RFC 1394는 지명, 전화 국가 코드, 텔렉스 국가 코드, 앤서백 문자, 인터넷 도메인을 하나의 날짜가 기재된 대조표로 모았습니다. 이 문서는 무엇이 실제로 운용 중이거나 권위 있는지가 아니라 무엇이 대응하는지를 기술했습니다.
  • 이 메모는 불확실성을 메우는 대신 드러냈습니다. 서로 다른 결측 표식을 사용하고, 일부 코드가 잘못되었을 수 있다고 경고하며, 세 가지 통신 수단으로 정정을 받았습니다.
  • 가장 날카로운 경계는 운영적이면서도 정치적이었습니다. 알려진 코드가 있다는 사실은 허용된 회선, 등록된 DNS 이름, 권위 있는 위임, 메시지 전달, 또는 한 나라의 지위에 대한 승인을 증명하지 못했습니다.

하나의 행이 여러 시스템을 연결했다

1993년 1월,RFC 1394는 실질적인 마찰을 줄이려 했습니다. 한 통신 체계에서 어떤 지역이 표기되는 방식을 아는 사람이 다른 체계에서의 표기는 모를 수 있었습니다. 이 메모는 지역 또는 국가 이름을 전화 다이얼 코드, 텔렉스 국가 코드, 앤서백 문자열, 인터넷 도메인과 맞춰 정렬했습니다.

이는 유용한 압축 작업이었습니다. 독자는 익숙한 하나의 값에서 출발해 나머지 후보를 찾을 수 있었습니다. 표에는 주요 공용 이메일 시스템과 미국 주 도메인 같은 하위 국가 단위 항목도 포함되어 있었습니다. 따라서 표에는 지리적 명칭, 번호 계획 값, 네트워크 이름 공간, 사업자별 주소라는 여러 종류의 참조가 섞여 있었습니다.

그러나 열들이 하나의 행을 공유한다고 해서 서로 바꿔 쓸 수 있게 된 것은 아니었습니다. 전화 접두 번호는 교환 시스템에 지시를 내렸습니다. 텔렉스 국가 코드와 앤서백은 다른 서비스에 속했습니다. 국가 코드 도메인은 DNS 이름 트리의 한 가지를 차지했습니다. 상업용 메일 시스템 명칭은 지역이 아니라 사업자로 이어질 수 있었습니다. 행은 이들 사이의 주장된 관계를 표현했을 뿐, 보편적인 변환 알고리즘이 아니었습니다.

결핍된 정보는 그대로 드러나 있었다

RFC 1394는 두 종류의 부재를 정의했습니다. 네 개의 대시 표식은 알려진 전화 코드가 없다는 뜻이었고, 세 개의 대시 표식은 그 외의 결측 또는 미확인 정보를 다뤘습니다. 이 작은 구분 덕분에 빈 칸이 하나의 의미를 몰래 얻는 일이 막혔습니다.

표 자체가 미완전함을 평범한 상태로 만들었습니다. 어떤 지역은 도메인은 있지만 기재된 텔렉스 앤서백이 없었습니다. 어떤 곳은 여러 텔렉스 코드를 가졌습니다. 어떤 이름은 역사적이거나, 대체 명칭이거나, 다른 관할권 안에 중첩되어 있었습니다. 여러 행이 하나의 도메인으로 수렴하는가 하면, 하나의 지리적 명칭이 여러 통신 값을 담기도 했습니다.

이 문서는 편집상의 주의가 그런 충돌을 해소한다고 주장하지 않았습니다. 정보는 여러 나라의 여러 출처에서 왔으며 정확성이 보장될 수 없고 일부 코드는 틀릴 수 있다고 명시했습니다. 정정은 우편, 이메일 또는 텔렉스로 받았습니다. 목록에는 관리자와 수리 경로가 있었지만, 인쇄된 모든 값을 사용 시점에 최신으로 만들어 주는 장치는 없었습니다.

이것이 발행된 관찰과 살아 있는 권위의 차이입니다. 관찰은 신중하고, 유용하고, 수정 가능할 수 있습니다. 그래도 오류의 비용이 클 때는 날짜, 출처, 이후의 확인이 여전히 필요합니다.

도메인 모양의 값이 곧 위임은 아니었다

국가 도메인 열은 이전의 명명 결정에 기반했습니다.RFC 920은 ISO 3166의 영문 두 글자 alpha-2 코드를 사용한 국가 최상위 이름을 기술했습니다. 또한 국가 도메인이 수립됨에 따라 관리자와 에이전트가 목록에 올라갈 것이라고 밝혔습니다. 코드의 출처, 허용되는 레이블, 도메인을 수립하는 행위는 서로 분리되어 있었습니다.

RFC 1034는 이후 그 분리에 운영적 형태를 부여했습니다. DNS는 이름 공간을 존(zone)으로 나눕니다. 서버는 트리의 경계가 정해진 부분에 대해서만 권위를 가지며, 응답은 권위 있는 데이터와 다른 존에 대한 캐시된 정보를 구분합니다. 위임은 이름 공간의 절단 지점에 레코드가 있고 하위 서버에 도달하는 데 필요한 정보가 있어야 성립합니다.

RFC 1394는 열에 두 글자를 인쇄함으로써 이러한 행위를 전혀 하지 않았습니다. 그 행은 독자에게 어떤 도메인이 어떤 지역에 대응한다고 믿어진다는 것을 알려줄 수 있었습니다. 하지만 위임을 만들거나, 관리자를 임명하거나, 현재의 네임 서버를 공개하거나, 그 서버들이 응답한다는 것을 증명할 수는 없었습니다.

이 경계는 반대 방향으로도 작동했습니다. DNS 위임이 작동한다고 해서 그 옆의 모든 전화 또는 텔렉스 코드가 여전히 유효하다는 보증은 되지 않았습니다. 각 시스템은 자신만의 운영자, 갱신 주기, 실패 양상을 유지했습니다.

익숙한 일부 접미사는 게이트웨이 표기에 불과했다

이 메모는 BITNET과 UUCP에 대해 특히 명확했습니다..BITNET이나.UUCP로 끝나는 이름은 해당 커뮤니티 안에서 사용되었지만 등록된 DNS 이름은 아니었습니다. 인터넷에서 이들에 도달하려면 메일을 변환해 게이트웨이를 통해 보내야 했으며, 이는 노트에 기술된 퍼센트 기호 라우팅 관행을 사용했습니다.

이 세부 사항은 흔한 역사적 오류를 막아 줍니다. 문자열이 도메인처럼 보이고 인터넷 지향 주소에 나타날 수 있지만, 위임된 DNS 가지로 존재하지 않을 수 있습니다. 겉보기 접미사의 DNS 조회가 아니라 게이트웨이가 다음 단계를 제공했습니다.

게이트웨이 경로는 전달 증명서도 아니었습니다. 그것은 중개자가 변환 방식을 알고 후속 처리를 위해 메시지를 받아들였다는 것을 보여줄 뿐이었습니다. 원격 커뮤니티, 목적지 시스템, 메일함, 사람 독자는 각자 고유한 증거를 가진 이후 단계로 남았습니다.

RFC 1394는.ARPA를 다르게 기술했습니다. 호스트와 네트워크의 역방향 조회에 사용되던 DNS 이름 공간의 역사적 부분이었습니다. 따라서 비슷한 문장 부호가 서로 다른 권위를 감추고 있었습니다. 구문만으로는 독자가 접미사가 위임된 DNS인지, 커뮤니티 표기인지, 게이트웨이 관행인지 판단할 수 없었습니다.

회선은 없을 수도, 금지될 수도 있었다

이 표의 가장 중요한 문장은 수많은 행 앞에 놓여 있습니다. 사용자가 한 나라에 도달할 수 있는지는 연결이 존재하는지, 그리고 연결이 허용되는지에 달려 있었습니다. 이 메모는 정치적 제한을 호출이 실패할 수 있는 이유로 명시했습니다.

이는 깔끔한 대조표라면 독자가 하나로 합치고 싶어할 세 종류의 기록을 분리했습니다. 첫째는 기술적 기록으로, 코드가 지역과 연관되어 있었다는 것입니다. 둘째는 운영적 기록으로, 이 시점에 이 출발지로부터 경로가 존재했다는 것입니다. 셋째는 허용적 기록으로, 당사자들과 적용되는 당국이 그 경로의 사용을 허가했다는 것입니다.

접촉 실패는 어느 계층이 실패했는지 알려 주지 않았습니다. 코드가 틀렸거나 낡았을 수 있습니다. 출발 네트워크에 경로가 없을 수 있습니다. 게이트웨이나 목적지가 다운되었을 수 있습니다. 정책이 연결을 금지했을 수 있습니다. 목적지가 응답하면서 수신자를 거부했을 수도 있습니다. 침묵은 그 지역, 그 사람, 코드의 유효성에 대한 판정이 아니었습니다.

반대 추론도 똑같이 위험했습니다. 성공한 연결은 어떤 경로가 교환을 완수했다는 것만 증명했습니다. 그것이 표를 다른 모든 서비스에 대한 권위로 만들거나, 향후 접촉에 대한 법적 권리를 확립하거나, 목적지 신원이 인증되었음을 보여 주지는 않았습니다.

목록은 국가성 판단을 거부했다

RFC 1394는 또한 한 나라의 이름이나 존재의 유효성에 대해 어떤 입장도 취하지 않았다고 밝혔습니다. 옛 이름과 대체 이름을 받아들였지만, 그 명칭들은 사람들이 행을 찾는 데 도움을 주기 위한 것이었고 편집상의 수록이 외교적 승인으로 취급되지 않았습니다.

옛 국가, 분쟁 중인 명칭, 영토, 사업자 네트워크, 국가 코드가 나란히 놓인 표에서는 이 절제가 중요했습니다. 목록은 지저분한 역사 속에서 사용자를 안내할 만큼의 기술적 유연성을 필요로 합니다. 모든 행을 헌법적 행위로 읽는다면 정정은 정치적 판결이 되고, 누락은 말살처럼 보이게 됩니다.

RFC 1591은 이후 최상위 도메인의 관리와 지정 관리자의 의무를 기술했습니다. 그 관리자들을 위임된 도메인의 수탁자로 지칭하고 운영 및 연락 책임을 요구했습니다. 또한 IANA는 무엇이 나라이고 무엇이 나라가 아닌지를 판단하는 일을 하지 않는다고 명시했으며, ISO 3166 목록이 별도의 절차를 제공했습니다.

그 이후의 메모가 코드를 주권으로 바꾸지는 않았습니다. 그것은 경계가 정해진 책임의 사슬을 보여 주었습니다. 한 기관은 국가 코드 출처를 유지하고, 다른 기관은 루트를 조율하고, 지정 관리자는 도메인을 운영하며, 네트워크는 그 아래의 서비스에 도달할지와 어떻게 도달할지를 선택합니다. 어느 것도 다른 것들의 권위를 전부 가져가지 않았습니다.

유용한 표는 얇게 유지되었다

RFC 1394는 보안을 다루지 않았습니다. 행에 대한 인증도, 접촉 상대의 동의 증명도, 게이트웨이가 저작자 정보를 보존한다는 보장도, 전달에 대한 감사 추적도 없었습니다. 그런 부재는 문서를 폐기할 이유가 아니라, 그 문서가 안전하게 수행할 수 있는 일을 정의합니다.

그 지속적 성과는 소박하지만 중요했습니다. 사용자가 불확실성을 다음 질문으로 바꾸게 해 준 것입니다. 어느 코드를 확인해야 하는가? 이 접미사는 실제로 등록되어 있는가? 어느 관리자가 권위를 가지는가? 여기에서 경로가 존재하는가? 연결이 허용되는가? 목적지가 메시지를 받아들였는가?

이 목록은 답들이 뭉개지지 않았기 때문에 유용했습니다. 대응 관계는 영토를 다스리거나 회선을 운영하거나 결과를 인증하지 않고도 문의를 이끌 수 있었습니다. 인터넷의 공통 계층은 참조를 이동 가능하게 만들고 실행을 실제로 그 권한을 가진 행위자들에게 맡길 때 가장 잘 작동했습니다.