그간 사내 보안규정에 따라 비공개 항목으로 분류됐던 한글인터넷주소의 기술적 설계에 관한 일부 내용을 공개하고자 합니다. 사내 내부결정을 거쳐 이번에 공개되는 한글인터넷주소의 설계 과정과 배경을 통해 자국어인터넷 주소가 어떻게 탄생돼 오늘에 이르게 됐는지를 이해하는데 큰 도움이 될 것이라고 생각됩니다.
1.MS사의 I.E 4.X 이전 버전에서는 주소창에 한글키워드 입력시 사용자가 지정한 N/S(네임서버)로 그대로 질의되는 과정을 거쳤습니다. 하지만 기존의 N/S는 1 Byte 문자만 처리할 뿐 한글과 같은 2 Byte 문자는 처리하지 못하는 등 한계가 있었습니다. 따라서 한글을 주소창에 입력하면 ‘에러(error)" 표시가 나왔던 것입니다.
{{또한 기존의 도메인은 영문인데다 [1byte] 도메인 설계시 그때 당시 네트워크와 컴퓨터 처리 속도 등을 감안해 분산형 구조로 만들어졌습니다. [1980년대]
그래서 도메인 구조는 tree모양의 분산형 형태를 갖추게 된 것입니다. 그 외 다른 군사적 이유도 있지만 넷피아는 키워드형 자국어주소 설계 당시에 물리적인 네트워크 속도와 컴퓨터 처리 속도가 가장 큰 관건임을 깨닫게 되었던 것입니다.}}
기존의 도메인은 이처럼 계층형인데 반해 넷피아가 추진하는 자국어 인터넷주소는 키워드형 비계층형(flat type) 주소 입니다.
이것이 가능한 이유는 1997년 당시 자국어주소가 발전하려면 사회적 과정을 함께 겪을 것이 분명하며, 그럴 경우 수년이 소요될 것이므로 물리적인 네트워크 속도와 컴퓨터 처리 속도에는 아무런 문제가 없을 것으로 연구팀에서 판단했기 때문입니다. 갑론을박 끝에 분산형구조가 아닌 집중형 root구조로 하되 시스템의 안정된 운영을 위해 각국의 여러 곳에 root를 배치하고 이것을 cluster화 하는 구조로 설계를 하게 되었던 것입니다.
IE 4.X 이전 버전의 경우, 주소창에서 키워드형 주소를 질의하게 되면 두가지 이유로 인해 에러가 나게 됩니다.
첫째, 기존의 도메인 네임서버는 1 byte 문자만 처리 되는 계층형인 반면 키워드형 주소는 비계층형(flat type)이어서 root Server에 등록되어 있지 않기 때문에 처리가 불가능했던 것입니다.
넷피아는 여러 가지 연구를 거듭한 끝에 계층형을 비계층형(flat type)으로 만드는데 성공했고, 기존에 없는 root를 새로 설계해 글로벌 NLIA[자국어주소] Root architecture를 만들어낸 것입니다.
과연 넷피아가 이 같이 엄청난 일을 해낼 수 있을 지 처음에는 의구심과 두려움이 들기도 했습니다. 하지만 결국 수년에 걸친 노력 끝에 전세계 95개국 자국어 인터넷주소의 새로운 root구조를 만들어내는 쾌거를 일궈낸 것입니다.
아울러 기존 네임서버에서는 1byte 문자만 처리 되는 것을 ngDNkit이라는 것을 개발해 2byte도 처리할 수 있도록 환경을 구축했던 것입니다.
그래서 모든 나라의 키워드형 언어를 도메인 네임서버에서 처리할 수 있게 설계하고, 자국어 주소 전용 네임서버를 전 세계에 보급하기 시작했던 것입니다. 국내에서는 주요 통신사[ISP]뿐 아니라 주요 대기업 학교 관공서 등에 관련 자국어 주소 지원용 네임서버를 보급하는 등 상당한 성과를 거두게 됩니다. 그런데 이상하게도 정통부 산하 인터넷진흥원과 관련된 기관에는 보급이 원천적으로 차단돼 아직까지 제대로 보급하지 못하고 있는 실정입니다.
이 밖에 대다수의 주요기관과 학교 기업 등에 이 같은 자국어 인터넷주소 네임서버와 자국어e메일주소 [이름@회사명]을 보급하고 있습니다.
현재 전자신문 등은 벌써 [기자명@신문사명]같은 형식의 한글메일을 약 3년째 사용중인 상황입니다.
일각에서 인터넷주소 자원 관리법 등을 인용하며 이 같은 서비스를 인4터넷주소가 아니라고 주장하고 있지만, 그것은 법에 누락이 된 것일 뿐 이미 보편적으로 사용되고 있다는 점에서 인터넷주소임이 틀림없습니다.
법으로 모든 것을 규정할 수는 없는 일이겠지요. 사실상 법은 금지 또는 의무규약이지, 미래에 만들어질 것을 미리 규약 하는 것은 아니라고 생각합니다.
표준이 만들어지기 전이라는 이유로 브라우저 제작사가 주소창에 입력한 한글주소를 주소가 아닌 검색으로 이동시키는 것은 용어의 정의에도 맞지 않는 부당한 행위라고 할 수 있을 것입니다. 주소창이라고 엄연히 명명되어 있음에도 검색으로 보낸다면 이는 개념상으로도 옳지 않다고 봅니다.
한국정보통신기술협회(TTA)의 [정보통신 단체표준 TTAS.KO-10.0127]은 한글인터넷주소 방식과 관련해 "이용자가 인터넷키워드 주소를 질의할 때 해당 객체주소로 변환하기 위해서는 반드시 이용자가 지정한 네임서버를 통해야 한다[제정일 :2001년 12월 19일]"고 명시하고 있습니다. 이는 넷피아가 주장해온 방식과 동일한 것이기도 합니다.
이 같은 점을 고려할 때 브라우저 제작사가 주소창의 한글 입력값을 자신의 검색업체로 자동으로 보낸다면 그 자체가 문제가 아닐 수 없습니다. 마치 하이재킹과 비슷한 행위라고 할 수 있을 것입니다.
단체표준의 취지는 브라우저 제작사가 주소창의 한글 입력값을 임의로 검색으로 돌릴 수 있도록 허용하지 않고 있다는데 있습니다.
표준에 따르면 "이용자가 인터넷주소를 질의할 때 해당 객체 주소로 변환[Resolve]하기 위해서는 반드시 이용자가 지정한 키워드 네임서버를 통해야 한다"고 명시돼있습니다.
이미 한국에는 이같은 내용의 표준이 세계 최초로 정해져 있는데, 이것을 위반하는 M사를 나무라는 대신 오히려 표준 지키기에 적극 나서고 있는 넷피아를 범죄인 취급하는 것은 천부당만부당한 일입니다. 이 같은 점에 대해서도 면밀한 검증이 뒤따라야 할 것입니다.
아울러 넷피아가 IETF에 올린 문서도 이번에 공개하니 참조바랍니다.
++++++++++++[IETF Draft 내용]++++++++++++++
키워드 네임 룩업 서비스 개요 ver 1.3
(실명형 인터넷 주소 서비스 개요)
넷피아닷컴 이판정, 배진현
2001.09.25
0. 머리말
본 문서는 새로운 인터넷 주소로 발전하고 있는 키워드 네임 서비스에 대해서 언급 하고자 한다. 특히 키워드 네임의 발전 배경과 사상적 배경에 대해서 말하고, 키워드 네임 서비스에 대한 기본 스펙을 설명한다.
1. 개요
인터넷은 현재 굉장히 빠른 속도로 발전되고 있으며, 인터넷이 발전함과 동시에 인터넷 서비스의 기반이 되는 인터넷 주소 역시 발전되고 있다.
지금 인터넷 주소는 점점 더 일반 사용자들에게 편리한 방향으로 발전되고 있으며, 이것은 다양한 노력으로 나타나고 있다.
현재 대표적인 인터넷 주소는, 인터넷의 시작과 함께 쓰인 IP Address, 도메인 네임 등을 대표적인 예로 들수 있다. 특히 도메인 네임의 경우는 사용자의 편리성을 높이기 위해, IDN으로 확장되고 있는 중이다.
그리고 이러한 IP Address, 도메인 네임 처럼 잘 알려진 인터넷 주소 이외에도, 키워드 네임이라고 불리는 신개념의 인터넷 주소가 활발하게 몇몇 그룹에서 논의 되고 있다.
이 문서에서는 인터넷 주소의 발전 방향을 알아보고, 새로운 개념의 인터넷 주소인 키워드 네임의 사상적 배경과 서비스 전반에 대해서 언급하고자 한다.
2. 소개
2.1 인터넷 주소의 발전 과정
현재 인터넷 주소는 IDN을 통해서 도메인 네임에 다국어를 이용할 수 있는 단계 까지 거의 발전하였다. 하지만 사용자 편리의 관점에서 본다면, IDN은 인터넷 주소의 최종 발전 단계가 아니라, 새로운 인터넷 주소로의 발전을 위한 하나의 시도였다고 볼 수 있다. 여기서는 현재까지 논의되는 인터넷 주소중에서 몇몇 이전의 draft에서 논의된 키워드 네임에 대해서 언급 하고자 한다.
인터넷 주소의 발전 과정을 살펴보면 다음과 같다.
1) IP Address (210.103.175.31)
2) Domain Name (netpia.com)
3) I18N Domain Name (넷피아.com)
4) Full I18N Domain Name (넷피아.회사.한국, 넷피아.회사)
5) Keyword Name (넷피아)
숫자의 조합으로 된 IP address의 개수가 많아 졌고, 단지 HOSTNAME으로 모든 인터넷에 연결되어 있는 서버들을 관리 하는것이, 시간이 흐름에 따라 더욱 더 불편하여 졌다.
이것을 해결하기 위해서 Domain Name이 나오게 되었지만, 이러한 도메인 네임도, LDH 만을 사용하는 제한적 네임스페이스 등의 문제점을 가지고 있었다. 그리고, 인터넷이 비 영어권으로 확대되어 자국어를 인터넷 주소로 사용하고자 하는 사용자의 요구가 점점 대두하게 되었다.
이에 IDN이 출현하게 되었지만, IDN도 완벽하게 사용자의 편리함을 지원하는 것이 아니었고, 아직까지 정식 서비스가 되지 않고 있다.
현재는 사용자에게 좀더 편리한 키워드네임까지 발전되었다.
위에서 살펴본, 1)에서 4)까지는 사용자의 요구에 의해 기술의 발전으로 진행되었다면, 5)는 사용자의 요구, 기술의 발전과 함께 반드시 법리적인 배경이 뒷받침이 되어야만 하는 새로운 개념의 인터넷 주소이다.
키워드 네임은 "인터넷 주소에서 식별체계, 즉, TLD, 2LD 등을 두지 않더라도 식별할 수 있는 방법이 있다면 더욱 좋은 체계이며, 이것이 진보된 인터넷 체계, 즉 진보형 인터넷 주소"라는 사상적 배경에서 출발하였다.
키워드네임의 법리적 배경을 살표보면 다음과 같다.
넷피아.co.kr
| |
| +-----> 한글 문자 코드 자체가 ccTLD 를 표현할수 있다.
| 즉, 자국어 코드가 .kr 에 해당된다.
+-------> 실정법상에서는 자국어 내에 기관의 분류가 내포되어,
2LD가 필요 없어진다.
시스템에 문자코드 판별시스템을 두어 문자코드 자체가 보다 다양한 ccTLD or TLD 역활을 하게 함으로써, 한글 인 경우에, 한글 Character 자체가 곧 ccTLD가 된다. 이것은 언어 자체가 국가의 식별체계가 되기 때문에, 굳이 .kr을 사용하지 않아도 되다는 것을 의미하며, 이러한 사상적 배경으로 .kr을 생략할수 있다.
또한 실정법의 실명속에는 이미 보다 다양한 기관의 분류가 내재되어 있기 때문에, 회사를 의미 하는 .co 가 생략가능하다. 예를들어 "서울시청.go.kr" 일경우 "서울시청" 이라는 키워드가 이미 정부기관임을 내포하고 있음을 알수 있다. 또한, "서울대학교.edu" 일 경우 "서울대학교" 라는 키워드로 이미 대학교임을 알수 있기에 굳이 ".edu" 를 사용하지 않아도 되는 것이다.
즉, 기관의 성격을 나타내는 ".co", ".go", ".or", ".edu" ... 등의
2LD(TLD)는 실정법상 실명이라는 것에는 기관의 분류가 이미 내재 하고 있다는 법적인 영역으로 생략 가능한 부분이다.
다시 설명하면, ccTLD, TLD는 문자 코드 판별 시스템으로 사용자 편의를 위하여 기계의 인식성과 (기계가 .kr 인식) 사용자의 인식성을 해결하였다.
실정법상의 실명속에는 이미 기존 도메인의 기관의 분류를 나타내는 2LD에 해당되는 기관의 분류인 인식표기 (ex: .co, .go, .or ... 등)가 보다 다양한 형태로 이미 내재되어 실명으로 사용되어지는 인터넷 주소에서는 기관의 분류를 표기되는 것을 생략해도 된다.
즉 인식의 관점에서 분류지워진 2LD와 TLD(ccTLD)가 기술의 개발, 발전으로 사용자가 직접 구별하여 입력할수도 있고, 사용자가 직접 구별하여 입력하지 않아도, 시스템이 자동화(지능화)되어 사용자의 편의성을 도와주는 시스템으로 진보 발전된 개념이다.
여기서 고려되어야 할 사항은 크게 두가지 인데, 첫째는 사용자적 관점에서의 세계적 범용성인데, 기존의 도메인은 사용자적 관점에서의 세계적 범용성은 영어와 그 조합이기에, 가능하지만, 각국의 자국어로 사용하는 키워드 네임은 세계적 범용성 보다는 언어권별, 행정권별 Local 형으로 설계 제작하였고, 영어 도메인이 세계적 범용성이 뛰어난 반면 Local적 도메인의 인식성에는 많은 한계를 갖고 있고, 일반 이용자로 하여금, 인터넷 주소 자체가 하나의 장벽(인터넷 사용의)인 것이 사실인 반면, 키워드 네임은 실명(자국어 or 자국어에서의 표기어)자체로 인터넷 주소화 함으로써 기존 도메인의 Local 적 인식성의 근원적인 문제점을 해결하였다.
둘째는 2LD와 TLD를 사용하지 않음으로 인한 시스템의 안정성과 사회과학적 안정성인데, 이 두가지는 넷피아가 지난 2년간 상용서비스를 한 결과, 기존 도메인 시스템 보다 훨씬 사용자 친화적 인터넷 주소로서 자리매김 하는데 성공하였다고 평가된다.
기존도메인의 경우 영문과 그 조합으로 사용되어지고 기관의 분류를 두는 이유는 영문의 특성상 확장어 보다는 축약어를 도메인으로 많이 사용 (인식률을 높이기 위함)함에 따라 그나마 기관의 분류값이 없으면 상당한 부분이 충돌이 <(자원의 희소성) - 같은 이름 충돌> 일어나지만 실명의 경우는 등록 정책상 축약어는 등록 가능하나 운영상 보장은 허용하지 않는 정책을 병행하여 기존 도메인에서 일어나는 동명 충돌 관계를 최소화 할수 있다. (법리적관계)
키워드 네임은 인터넷 주소가 사용자 중심의 편리성에 따라 변화, 발전해 가는 역사를 그대로 따라서 나타난것으로, 기존의 복잡한 인터넷 주소가 가진 한계성과 일상생활에서 사용하는 실명(자국어)을 사용할 수 없다는 제한성을 극복하여 사용자에게 보다 쉽게 인터넷을 사용할 수 있도록 하기 위한 것이다. 앞에서 말한 것과 같이, 인터넷 사용자들의 요구와, 기존의 인터넷주소들이 기술적, 법리적으로 발전하여 나타난, 인터넷 주소의 새로운 진보된 형태라고 말할수 있다.
2.2 키워드 네임 서비스의 개요
키워드 네임 서비스는 기존 도메인 네임에 이어 또 하나의 키워드 형태의 실명 인터넷 주소로서 각국의 자국어와 영어로 주로 사용되며, 인터넷에 연결 된 서버 주소를 나타내는 표지로, 기관명 및 상호, 상표, 서비스표, 개인의 이름, 전화번호, 햄 및 호출번호, Barcode 등의 unique한 정보와 연결하여 주는 것이다.
법적 영역의 범위는 해당명의 사용적, 상업적 범위가 해당 지역의 법적인 영역의 테두리 안에서 서비스 되어져야 한다. 또한 키워드형 인터넷 주소는 사용자의 인식의 관점에 정의된 찾을려는 값을 사이버 세상의 주소로 부여한 것이다.
2.3 특징
키워드 형태로 표현되는 사이버 주소의 특징은 유니크 한 모든 부분을 표현할 수 있는 특징이 있는 바, 사용자가 인식하는 유니크 한 모든 부분을 표현 가능하여야 한다.
키워드 서비스는 실정법상의 법적인 영역이 존중되며 운영되는 바 실정법상의 네임 자체에는 기존 도메인 의 기관의 분류를 나타내는 기관의 분류 값이 이미 내재되어 의미적으로 Name space를 충분히 확장할 수 있는 특징이 있으며 손쉬운 확장어 역시 Name space 부족을 기존 도메인에 비하여 상대적으로 용이하게 하는 장점이 있다.
이 서비스 역시 기존 도메인 네임과 같이 인터넷 주소로서의 모든 요구조건을 충족시키기에는 한계를 가지고 있지만 손쉬운 확장어는 많은 부분 이것을 해소하고 있고, 기존 도메인에 비하여 Name space의 확장성이 높은 사용자의 인식성이 높을 뿐만 아니라 가장 중요한 사용장의 편리성이 높다는 (특히 비영어권에서) 큰 장점이 있다고 분석할수 있다.
3. 현재까지의 키워드 네임 서비스
그 동안 키워드 네임을 지원하기 위해 다양한 노력이 있었고, 크게 4단계의 방식이 있었지만 인터넷의 미래와 보다 많은 인터넷 사용자를 위하여 다음의 요구사항에 가장 흡족히 충족 되는 방식으로 발전되어야 한다.
서비스 방법 중에 하나로 응용 프로그램 별로 키워드 서비스를 제공하는 방법이다. 이것은 사용자의 입력값을 특정 서버로 보내는 방법으로 서비스하기에는 손쉽고, 간단한 방법이나, 각 응용프로그램마다
키워드 네임이 다른 값을 응답할수 있으며, 특히 같은 종류의 응용프로그램에서 다른 값을 응답 할수도 있다. 이것은 키워드 네임을 인터넷 주소로 사용하고자 하는 사람들에게 많은 혼란을 야기 시킬수 도 있다. 즉 통일성이 부족하다. 오히려 이것은 인터넷주소가 아니라 인터넷주소의 pc통신화(각 시스템 별 서버를 두고 서비스하는 서비스회사별 폐쇄형 통신 서비스)이지 통일성이 요구되는 인터넷주소 서비스는 아니다.
그리고 OS 리졸버나, 네트워크 장비에서도 키워드 서비스를 제공하려는 다양한 노력이 있다. 하지만 이것은 아직 실험적인 단계이며, 많은 사람들에게 서비스를 제공하기 위해 학산하는데 많은 시간이 필요하다. 현재로서는 확장성과 보편 타당성 부족하다.
NS로 질의 되는 값을 이용하여 서비스하는 방법도 여러곳에서 다양한 방법으로 시도되고 있다. 이 방식은 각종 응용프로그램에서 키워드 네임이 입력시 NS로 입력값이 (어떤 경우는 사용자가 입력한 값이 아닌경우도 있지만) 전송된다는 것에 아이디어를 내어 서비스를 제공하는 방법이다.
실제로 네임서버를 확장하려는 노력은 매우 다양한 모습으로 나타나고 있다. 이러한 얼터느티브 NS 또는 NS를 확장 하는 서비스는 다양한 어플리케이션에서 질의되는 쿼리들을 능동적으로 받아들여 원하는 서비스를 제공할수 있다는 장점이 있다. 이는 여러 종류의 사용자적 어플리케이션에서 키워드 네임을 질의시 동일 값을 응답할 수 있다는 장점이 있으며, 이것은 인터넷 주소가 가지는 유니크 한 결과 값을 제공할 수 있다는 것을 의미한다.
물론 DNS는 키워드 네임을 서비스 하기 위해서 만들어진 것이 아니지만, DNS를 이용하는 방법은 우리에게 키워드를 서비스하기 위해서 무엇을 해야 하는지 알려 주었다. 네이밍 서비스라는 것은 모든 어플리케이션에서 공통적으로 유니크한 서비스를 받을수 있어야 하는 것을 의미하며, 키워드 네임도 여기에 해당 한다. 즉 통일성에 적합하다.
우리가 앞으로 키워드 네임 서비스를 할려면 단순히 응용프로그램의 지원만을 생각하는 서비스는 지양하여야 할것이다. 키워드 네임 서비스는 키워드 네임이 인터넷 주소의 역할을 다할수 있도록 어떤 사용자적 어플리케이션에서든지 손쉽게 사용 되어야 하고, 기존 서비스에 별다른 영향을 끼치지 말아야 하며, 추후 어떠한 종류의 인터넷 응용 프로그램이 나와도 손쉽게 확장될수 있어야 한다.
4. 키워드 네임 서비스
4.1 개요
현재 우리의 실생활에서는 나의 존재를 알아낼수 있는 다양한 식별인자가 있다. 개인 홈페이지 주소, E-mail, ICQ 번호, 전화번호, 핸드폰 번호, 팩스 번호, 실제주소 등등... 우리가 다 생각하지 못할 정도의 다양한 식별 인자가 있다.
그리고 이미 이러한 다양한 식별인자들은 우리 주변에서 별다른 문제없이 잘 사용 되고 있으며, 인터넷으로의 서비스 확장도 별다른 무리없이 진행되고 있다.
실제, 저자는 PC에서 팩스를 보내고, PC에서 전화를 거는 작업을 자주하고 있다.
또한, 한국에서는 인터넷에서 E-mail 을 보내면 실제 우편이 배달되는 서비스도 존재하고 있다.
키워드 네임은 이러한 다양한 식별인자를 좀더 손쉽게 연결하는 방법을 제공하게 될것이다. 실제 나는 친구에게 인터넷으로 팩스를 보내기 위해 그의 팩스 번호 찾는데 상당한 노력을 기울였다. 하지만 만약 내가 인터넷 팩스 프로그램에
그의 이름만을 입력함으로써 팩스가 보내질수 있다면 좀더 편리할것이라는 하는 생각을 하게 되었다.
이것은 팩스번호 만의 문제가 아닐것이다. 우리는 다양한 식별인자를 기억하기 여러가지 노력을 하고 있으며, 때로는 해당 식별 인자값을 당장 알아내지 못해 많은 곤란을 겪은 경험도 있을것이다.
이러한 문제들은 키워드 네임이 서비스 됨으로써 상당부분 해결하여 줄 수 있는 문제라고 생각되어진다. 키워드 네임이 팩스 프로그램 뿐만 아니라 다른 여러 응용프로그램에서도 동일하게 사용될수 있다면 훨씬 더 편리하게 될 것이다.
4.2 KNS
앞에서 말한것과 같이 키워드 네임은 DNS와 마찬가지로 다양한 어플리케이션에서 질의 되는 내용을 처리할수 있는 네이밍 시스템의 형태로 가야 할것이다.
그것을 기존의 DNS와 구별하여 KNS(Keyword Name Server)로 정의하고자 한다.
+--- 네이밍 시스템 -----------+
| +----------+ +-----------+ |
| | | | | |
| | DNS | | KNS | |
| | | | | |
| +----------+ +-----------+ |
+-----------------------------+
4.3 클라이언트 서버 모델
DNS 체계와 마찬가지로 KNS역시 C/S 모델로 되어야 할것이다.
다양한 사용자의 요구에 대해서 서버는 해당 요청을 별 문제없이 수행할 수 있어야 하며, 그러기위해서 프로토콜이 좀더 가볍고 오버헤드를 줄일수 있는 C/S 모델이 되어야 한다. 특히 새로운 프로토콜이 네트웍의 부하를 주지 않도록 많은 노력을 해야만 할 것이다.
5. 요구사항
아래에 기술할 요구사항에서는, 제공되는 측면과 관련되는 것은 "서비스"로, 비교적 구현과 관련된 것은 "프로토콜"이라고 명명한다.
5.1 호환성에 대한 요구사항
[1] 서비스는 DNS와 별도의 시스템이어야 한다. 현재의 DNS는 인터넷의 그 자체라고 할정도로 굉장히 중요 부분이다. DNS와는 별도의 네이밍 시스템으로 진행하여야 한다. 그리고 충분히 안정성이 검증된 후에 DNS와의 통합도 노력해야 할 것이다.
[2] 키워드 네임 서비스는 인터넷에 있는 여러 식별인자 중 가장 기본인 IP Address를 바로 응답할수 있지만, 그렇지 못한 경우도 있기에 DNS등의 참조가 필요하다.
[3] 같은 키워드에 대한 서비스 요청에 대해서는 캐쉬 서버인지 루트 서버인지에 관계없이 같은 응답을 돌려주어야 한다.
[4] 요청된 쿼리의 키워드가 캐쉬의 시간이 종료되었을 경우 캐쉬서버는 응답을 하지 않아야 한다.
[5] 프로토콜은 특정 캐릭터셋에 의존하지 않는다.
[6] 언어별(코드별)로 유니크한 키워드 네임이 서비스 되어야 한다.
5.2 국제화에 대한 요구사항
[1] 서비스에 사용되는 코드는 유니코드를 기준으로 확장되어야 한다.
[2] 프로토콜은 서비스 하기전에 키워드에 대해서 Name Preparation이 이루어져야 한다.
[3] Name Preparation을 고려하여 키워드에 대한 혼란을 줄어야 한다.
[4] Case mapping의 경우 대부분의 사용자가 소문자를 사용하므로 대문자를 소문자로 mapping한다.
[5] 서비스는 사용자의 언어 기반으로 이루어져야 합니다.
5.3 운영에 대한 요구사항
[1] 서비스는 1:1 매칭에 대해서만 고려한다.
[2] 키워드 테이블은 수정이 용이하여야 한다.
[3] 키워드 네임 시스템는 기존의 DNS의 트래픽에 영향을 주어서는 안된다.
[4] 키워드는 사용하는 캐릭터셋으로 분류되어 같은 캐릭터셋을 사용하는 키워드끼리 관리되어야 한다. 서로 다른 캐릭터의 키워드가 같은 테이블에 존재해서는 안된다.
이때 사용하는 캐렉터셋은 유니코드를 기준으로 확장된것을 말한다.
[5] 키워드는 인터넷 리소스와 n:1의 관계를 가진다. 이때 인터넷 리소스는 키워드에 대한 정보 테이블을 말한다.
[6] 하나의 키워드 테이블내에서 키워드는 유일해야 한다. 서로 다른 테이블의 경우에는 의미적으로 같은 뜻을 내포한다 할지라도 중복될 수 있다.
[7] 테이블의 분류는 유니코드에 정의된 것에 따라 관리한다.
[8] 테이블내에서 키워드는 대소문자 구별이 없다. 따라서 abc와 ABC가 같은 테이블에 공존할 수 없다. 둘다 있을 경우는 하나는 무시된다.
6. Structural Overview
6.1 Interoperable view
A B
+------------+ +---------+ +--------+
| | 질의 | | 질의 | |
| Individual |--------->| KNS |-------->| KNS |
| User |<---------| Servers |<--------| Root |
| | 리소스 | at ISP | 리소스 | Server |
| | | | | |
+------------+ +---------+ +--------+
사용자가 다국어 키워드를 애플리케이션에 입력하면 이 다국어 키워드는 유니코드 문자열 형태로 사용자가 지정한 키워드 네임서버(A)로 전달된다.
이 키워드 네임서버(A)에서는 먼저 여러 개의 루트 키워드 네임 시스템 중에 한 곳(B)으로 해당 쿼리를 전달한다.
해당 루트 서버(B)에서는 유니코드 베이스로 된 문자열의 캐릭터셋을 확인하고 해당하는 리소스를 응답한다. 그리고 키워드 네임서버 A 는 해당 키워드에 대한 캐쉬를 하여 다음부터는 A에서 응답을 한다.
그리고 이때 질의 내용은 최소한 다음과 같은 정보를 가지고 있어야 한다.
[1] 키워드 네임
[2] 리소스 정보(어플리케이션 정보)
[3] 언어 정보
6.2 Client Side
Local Foreign
|
+--------+ Local Code+------+ Unicode| +---------+
| | String | | String | | |
| User|---------->|Resol-|--------|-->| KNS |
| Appli- |<----------| ver |<-------|---| Servers |
| cation | 리소스정보| | 리소스 | | |
+--------+ 정보 +------+ 정보 | +---------+
|
국제화된 자국어 키워드 서비스가 가능하기 위해서는 사용자의 애플리케이션 에서의 변경이 필요하다. 다시 말해서 Resolver에서 국제화된 캐릭터에 대한 고려가 필요하다. 키워드 자체에 대한 인코딩 뿐만 아니라 해당 클라인언트의 로케일 정보, 요청하는 프로토콜의종류(예를 들면, http, ftp, irc) 등에 해당 정보 등이 이에 해당한다. 캐릭터 인코딩 모델에 관련된 용어정의는 유니코드 테크니컬 리포트 17 [UTR17]에서 참고 할 수 있다.
참고) Packets은 유니코드의 키워드 뿐만 아니라 로케일 및 프로토콜의 형태를 포함한다.
리졸버를 통해 전달된 패킷은 사용 언어에 대한 정보를 담고 있다. 따라서 해당 로케일에 대해 권한을 가지는 서버의 주소로 문자열을 전달한다.
권한을 가지는 서버(Root 서버)에서는 관리하고 있는 키워드 테이블 중에서 전달된 문자열과 일치하는 키워드가 존재하는 지에 대한 여부를 판단하고 일치하는 경우 리소스정보를 리턴한다.
키워드 네임서버는 키워드에 대해서 다음과 같은 질의 순서를 따른다.
[1] 현재 관리하고 있는 캐쉬에서 키워드와 일치하는 것이 있는 지 검색 한다. 존재할 경우 키워드에 대한 리소스 정보를 알려주고 존재하지 않을 경우 루트서버 참조를 요청한다.
[2] Root Server는 요청된 키워드에 대한 리소스 정보를 리턴한다.
일치하는 정보가 존재하지 않을 경우 "NOT FOUND"로 처리한다.
6.4 캐쉬서버와 루트서버
캐쉬서버는 별도의 시스템이 아니며 단지 권한을 가지는 키워드 zone파일이 없는 KNS를 캐쉬서버라 한다. 이것은 한 번 질의된 키워드에 대한 응답 정보를 정해진 시간동안 캐쉬하게 되며 이 시간동안 같은 키워드에 요청에 대해서는 직접 응답을 해준다. 단 권한을 가지는 서버로 부터의 응답을 나타내는 플래그는 빠져있게 된다.
만약 캐쉬되어 있지 않은 키워드에 대한 요청이 있다면 루트서버에 해당 키워드를 질의하게 된다.
6.5 응용 프로그램에서의 이용
현재 인터넷 기반의 응용 프로그램은 많은 종류가 있다. 이렇게 다양한 형태의 응용 프로그램마다 요구하는 키워드 네임에 대한 리턴값이 조금씩 다르다. 웹 브라우져의 경우, 요청한 키워드 네임에 대한 응답으로서 URL을 기대할 것이다. 메일 클라이언트라면, 키워드네임 입력에 실제 E-mail Address가 응답되어야 한다. 이것은 같은 키워드 네임에 대해서 응용 프로그램에 따라 다른 식별 인자를 기대한다 것을 뜻한다. 멀지 않은 미래에, 우리가 사용하는 일반 전화기에서 "키워드 네임"을 말하면 해당하는 전화번호가 응답되어 전화기가 자동으로 전화를 걸어주는 서비스가 나타날 지도 모른다. 우리는 이 모든 것을 생각한 시스템을 고안 하여야 한다.
위와 같은 요구조건을 충족시키기 위해서는, 키워드 네임 시스템은 정보 그룹과 매핑 되어야 한다. 그리고 이러한 정보들은 지금 사용되고 있는 응용프로그램, 그리고 미래에 사용되어질 응용프로그램에서 손쉽게 이용할수 있도록 확장을 고려하여 구축되어야 한다.
키워드 -+- Applicaton1 - Application1 해당 값
+- Applicaton2 - Application2 해당 값
+- Applicaton3 - Application3 해당 값
키워드 네임 시스템은 영어권만을 지원하기 위한 서비스가 아니다.
국제적인 서비스를 지원하기 위해 다양한 언어를 지원하여야 할 것이다. 현재까지 국제화된 서비스를 지원하기 위해서 인코딩 방법에 있어서 유니코드를 보통 사용하고 있으나, 키워드 네임 시스템은 유니코드 뿐만 아니라 각 나라의 로컬코드도 모두 지원하여 좀더 확장성 있는 서비스가 되어야 할것이다.
또한 키워드 서비스는 로컬 서비스 기반이 되어야 할것이다. 해당 로컬에서만이 가장 잘 법리적으로 지원할수 있을 것이다. 키워드 네임 시스템은 단지 기술만이 아닌 법리적인 부분과 함께 발전되는 서비스이기 때문에 이부분을 고려하지 않을 수 없다.
7. 맺음말
위에서 언급한 것과 같이 키워드 네임 시스템은 기존의 서비스에, 어떠한 수정이나, 변화를 주지 않고 단지 기존의 외우기 힘들고, 입력하기 어려워던 다양한 리소스들에 대한 접근을 좀더 쉽게 하기위한 연결서비스가 되어야 할것이다.
8. 저자 연락처
Panjeong Lee
Netpia.com, Inc.
35-1, Youngdeungpo-Dong 8-ga, Youngdeungpo-Gu Seoul, Korea 150-038
Tel : +82-2-2165-3044
Fax : +82-2-668-4913
E-mail: pjlee@netpia.com
Jinhyun Bae
Netpia.com, Inc.
35-1, Youngdeungpo-Dong 8-ga, Youngdeungpo-Gu Seoul, Korea 150-038
Tel : +82-2-2165-3060
Fax : +82-2-668-4913
E-mail: piano@netpia.com
9. 용어정리
[1] LDH
: Letters, Digits, and Hyphen
[2] Keyword Name or Keyword
: 실명 인터넷 주소 - Legal Name Internet Address 를 나타내는 것으로 초기 Serch Model사에서 사용된 이름. R사의 경우 초기에는 Search 모델이었고 그래서 Keyword 라는 이름이 붙여졌고, 지금은 R사 역시 Search 모델이 아니라 인터넷 주소로서의 모델로 서비스 하고 있다. 그러기에 검색에서 사용되는 Keyword 라는 말보다는 Real Name Internet Address 등의 표현이 더 정확하다고 봄.
10. Reference
[RFC811] "Hostnames Server", RFC 811.
March 1982, K. Harrenstien
[RFC1034] "Domain Names - Concepts and Facilities", RFC 1034.
November 1987, P. Mockapetris.
[RFC1035] "Domain Names - Implementation and Specification", RFC 1035.
November 1987, P. Mockapetris.
[DIRECTORY] "Definitions for talking about directories".
draft-alvestrand-directory-defs-02.txt.
April 2001, H. Alvestrand.
[DNSROLE] "Role of the Domain Name System".
draft-klensin-dns-role-01.txt.
May 2001, J. Klensin.
[DNSSEARCH] "A Search-based access model for the DNS".
draft-klensin-dns-search-01.txt.
July 2001, J. Klensin.
[ARROUYE] "Keyword Lookup Systems As a Class of Naming Systems"
draft-arrouye-kls-00.txt
August 1, 2001, Y. Arrouye and V. Parikh and N. Popp
[SLS] "Service Lookup System".
draft-mealling-sls-00.txt.
July 2001, M. Mealling and L. Daigle.
[CNRP] "Common Name Resolution Protocol", draft-ietf-cnrp-10.txt.
June 2001, N. Popp, M. Mealling, and M. Moseley.
[UNICODE] The Unicode Consortium, "The Unicode Standard". Described at
http://www.unicode.org/unicode/standard/versions/.
[UTR15] "Unicode Normalization Forms", Unicode Standard Annex #15,
http://www.unicode.org/unicode/reports/tr15/, 2000-08-31,
M. Davis and M. Duerst, Unicode Consotium.
[UTR21] "Case Mappings", Unicode Technical Report #21,
http://www.unicode.org/unicode/reports/tr21/, 2000-09-12,
M. Davis, Unicode Consortium.
+++++++++++++++++++++++++++++영어원문 ++++++++++++++++++
INTERNET-DRAFT JH. BAE
May 20, 2002 PJ. LEE
Expires Nov 20, 2002 Netpia dot Com
Native Language Internet Address System (NLIAS)
draft-jhbae-nlias-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress."
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This Draft is to introduce Native Language Internet Address Service
that becomes popular as an alternative Domain name service.
This draft describes the backgrounds, rationale and the
specification of the Native Language Internet Address Service.
Generally in internet service when user types a word to connect to
the sepecific website, a quey typed in is so called as Keyword.
However, keyword is a word used to descibe the service, which is to type a word related to the information the user wants to get in the serach engine. So the author, myself, would like to use Native
Language Internet Address instead of Keyword.
JH BAE & PJ LEE [Page 1]
Internet-Draft NLIAS November 2001
1. Overview
As Internet service and the Internet infrastructure grow very fast,
Internet Name Service that is a basis for the Internet service is also
being developed rapidly. All the development is being carried out to
give more convenience to the Internet users and these efforts are
shown in many ways.
IP address and DNS(Domain Name System) are the general Internet addressing schemes from the start of the Internet era to nowadays. In case of DNS service, it is being extended to IDN for the convenience of end users. In addition to these traditional addressing schemes, a new approach, called Native Language Internet Address, is actively being discussed among in the Internet society.
This document surveys the development trend of Internet Addressing schemes and describes the rationale and the architecture of Native Language Internet Address Service as an alternative Internet Addressing schemes.
2. Introduction
2.1 Development of Internet Address
Internet Address, as of today, has been advanced to allow multilingual characters in the domain names using IDN. However, from the viewpoint of the end user convenience, IDN is not an ultimate destination of the Internet Address development, but it is just one of the intermediate steps.
Among many Internet addresses, this document discusses the Native Language Internet Address Service that has been discussed in a few drafts.
The development stages of Internet Addresses are as follows:
1) IP Address (210.103.175.31)
2) Domain Name (netpia.com)
3) I18N Domain Name (넷피아.com)
4) Full I18N Domain Name (넷피아.회사.한국, 넷피아.회사)
5) Native Language Internet Address (넷피아, Netpia)
JH BAE & PJ LEE [Page 2]
Internet-Draft NLIAS November 2001
As the number of IP address which is a combination of numbers has increased, the server management with only host IP addresses and host names becomes more inconvenient. To resolve this problem, domain name has emerged. Domain name, however, also has problems of limited namespaces using LDH[1] only. As the Internet has spread to non-English speaking countries, the need for using their own characters as Internet Name has increased.
As a result, IDN(Internationalized Domain Name) has emerged but it neither provide the community with the full convenience, nor is
fully serviced as well. Now, more convenient addresses, known as, Native Language Internet Address has emerged.
From, above 1) to 4), the technical advancement has been
achieved through the need of community. Native Language Internet Address, 5), is, conceptually, a brand new Internet address requires legal support as well as the technical advancement and community"s need.
Native Language Internet Address is based on the assumption that it is better to recognize an Internet address without current Internet
addressing hierarchies such as TLD and 2LD, and this is a more
advanced Internet addressing schemes.
A legal background of Native Language Internet Address is as follows.
넷피아.co.kr
| |
| +-----> Hangul character itself can express the ccTLD.
| That is a character code corresponds to .kr.
+-------> It identify the characteristic of organizations
according to the traditional trademark principles.
Therefore, 2LD becomes unnecessary.
The character sets or languages can be used as ccTLD or TLD by character set identification system. For example, Hangul character set itself becomes ccTLD. This means that the language itself can identify the country so .kr is not needed any more and can be omitted.
Also, the traditional trademarks already imply the organizations.
So the `.co", which implies company or corporation, can be omitted.
For example, in "서울시청.go.kr", the Native Language Internet Address
"서울시청" (City hall of Seoul), itself identifies the governmental
organization. As an another example, in "서울대학교.ac.kr", the Native
Language Internet Address, since "서울대학교" (The Seoul National
University) itself implies the educational institution ,".ac" is
notnecessary.
That is, 2LD such as ".co", ".go", ".or", which identify the
characteristic of organizations already according to the traditional
trademark principles, so it can be omitted in the domain names.
JH BAE & PJ LEE [Page 3]
Internet-Draft NLIAS November 2001
In other words, ccTLD and gTLD can be resolved by the character set identification system. By the traditional trademark principles, the
trademark name itself identifies 2LD and the organization, for example, .co, .go, .or and etc. As technology advances, the system
can identify the 2LD or TLD(ccTLD) from the name even if the user does not specifies it. It is a kind of more advanced system so that the users can use the internet more conveniently.
There are two more important advantages in this approach.
First, from the user"s point, the availability of internet is one
factor to consider. In the traditional domain system, the domain is
the combination of English alphabets and numbers designed for
universal use. However, this can be an obstacle to the Internet access for the non-English speaking people. But the Native Language Internet Address can identifiy the Internet Address by the very real name in the native language or notation, which make the Internet more available to the local, non-Enlgish speaking people. Second, the stability and the user friendliness of the system without using 2LD or TLD are another advantage of the system, which has been verified by the commercial service experience of the last 2 years.
In the traditional domain names, as the combination of English
alphabets, in an abbreviated form, are used for the name, the
organization identification is needed to reduce the conflict of the
names. In Native Language Internet Address, a real trademark or a name is used in itself. The conflict can be minimized by using the real name, although the registration policy permits abbreviated name by warning the possible conflict. (legal issues)
Native Language Internet Address has emerged as a result of Internet Address development toward the convenience of the community and it made the Internet more accessible for the community by using the real names in its native language, which was not possible in the traditional Internet Addressing scheme. As mentioned above, Native Language Internet Address is an advanced method derived from the community needs and the technical and legal developments of traditional internet addresses.
2.2 Overview of Native Language Internet Address Service
Native Language Internet Address Service connects the traditional
domain name to the unique information such as organizational name, trademark, service name, person"s name, telephone number, HAM or pager number, barcode and so on. Native Language Internet Address
should be serviced in a regional legal boundary. Also, Native Language Internet Address is provided by user"s locale information to map that information with the address of the cyber world.
JH BAE & PJ LEE [Page 4]
Internet-Draft NLIAS November 2001
2.3 Characteristics
Since the characteristics of Native Language Internet Address can
express all the unique aspects of a given name, it should include all unique identifiers that a user can understand. Because Native Language Internet Address Service respects the registered names and can extend the implied name space easily, the name space shortage problem can be relatively alleviated.
Although it fails to satisfy all the needs of Internet Address as any
other method, it enhances the accessibility and convenience of the end user, especially in non-English speaking regions.
3. Current Native Language Internet Address Service
Until now, four different attempts have been tried to provide the
Native Language Internet Address Service.
The following requirements should be satisfied for the future of
Internet and its community.
1) by application
2) by OS support
3) by network device
4) by N/S extension
One of the service methods is to provide Native Language Internet
Address Service by every application. This method is simple and easy method to do service, but each implementation may be responded with different answers. This causes a lot of confusions to the community who uses Native Language Internet Address as Internet Address, that is, it lacks the uniformity. This makes the Internet as a closed private service like most of the local communication service provides, which is not the goal of Internet service.
Another try is to enhance the OS resolver or to use special
networkdevices to provide the Native Language Internet Address Service But these methods are still in the experimental stage and lots of time and efforts are needed to apply these methods to the community.
For now, these lack the extensibility and the universal validity.
JH BAE & PJ LEE [Page 5]
Internet-Draft NLIAS November 2001
Yet another method that uses the NS query is being tried in many ways.This method is based on the fact that, in many applications, the Native Language Internet Address typed in (though sometimes this is not the case) by the end user is transferred to the NS. In fact, there are various attempts to extend the name server. These alternative NS or extended NS can actively respond to the queries from various applications.
This method has advantages that it can provide the same response from different applications, which means that this can provide the uniqueness of the Internet Address.
Even though DNS was not made to provide the Native Language Internet Address Service, it gives a hint on what should be done to provide the Native Language Internet Address Service. Naming Service should provide an unique service for the various applications. Native Language Internet Address Service falls on these category. That means that it can provide consistency.
Future Native Language Internet Address Service must support not only specific application program, but also the general naming scheme to be usable as an Internet Address. It should be compatible with the existing service and easily extensible to the future Internet applications. And it also shouldn"t affect the existing services.
4. Native Language Internet Address Service
4.1 Overview
There exists many identification methods for our daily lives
a personal home page, e-mail, ICQ number, telephone number, fax number and snail mail address are examples to name a few.
These identifiers are used in a real life without serious problems
and it is being extended to the Internet service. In fact, I send fax
and telephone calls using the desktop PC. Also, there is some service providers which allows users to have an effect of sending a snail mails just by sending an e-mail in Korea.
Native Language Internet Address will provide a framework to
interconnect these identifiers easily. For example, I have to search
the address book many times to send some faxes to my friends. If there is a fax program that can send just by typing the name of receiver, the service would be much convenient.
This problem is not limited to the fax number. We have many problems to memorize many identifiers and sometimes we even fail to find the specific identifier we need. It would be more convenient to use Native Language Internet Address Service not only for the fax program but also for many other application programs.
JH BAE & PJ LEE [Page 6]
Internet-Draft NLIAS November 2001
4.2 NLIAS (Native Language Internet Address System)
As mentioned above, Native Language Internet Address should evolve as a form of Naming System which can resolve the queries generated from various applications. Differentiating this service from DNS, we call it as NLIAS(Native Language Internet Address System).
+--- Name Server -------------+
| +----------+ +-----------+ |
| | | | | |
| | DNS | | NLIAS | |
| | | | | |
| +----------+ +-----------+ |
+-----------------------------+
4.3 Client Server Model
The Native Language Internet Address System should be a C/S model like Domain Name System. The server should respond to the queries without difficulty from various users. For this, a C/S model is adequate because it is simple and it reduces overhead. Especially, the new protocol should not increase the network loads.
5. Requirements
For the technical requirements described below, we define a "service" for those related to something provided to the end users and we define"protocol" for those related to implementation.
5.1 Requirements for Compatibility and Interoperability
[1] Service should be a separate system from DNS. In these days DNS is so important that it can be referred as Internet itself. It should be a separated Naming System from DNS. After the verification of stability, the attempts to integrate into DNS should
Ȩ
/ Խ
