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단계의 방식이 있었지만 인터넷의 미래와 보다 많은 인터넷 사용자를 위하여 다음의 요구사항에 가장 흡족히 충족 되는 방식으로 발전되어야 한다.

1. 사용자의 편의성
2. 통일성
3. 확장성 (name space의 확장성, service의 확장성)
4. 안정성
5. 인식성
6. 보편타당성

서비스를 제공하는 방법을 알아보면 다음과 같다.

1) 응용프로그램 방식
2) OS 방식
3) 네트워크 장비 방식
4) N/S 확장 방식

서비스 방법 중에 하나로 응용 프로그램 별로 키워드 서비스를 제공하는 방법이다. 이것은 사용자의 입력값을 특정 서버로 보내는 방법으로 서비스하기에는 손쉽고, 간단한 방법이나, 각 응용프로그램마다
키워드 네임이 다른 값을 응답할수 있으며, 특히 같은 종류의 응용프로그램에서 다른 값을 응답 할수도 있다. 이것은 키워드 네임을 인터넷 주소로 사용하고자 하는 사람들에게 많은 혼란을 야기 시킬수 도 있다. 즉 통일성이 부족하다. 오히려 이것은 인터넷주소가 아니라 인터넷주소의 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]에서 참고 할 수 있다.

6.3 Server Side
+-------+ +-------+ +--------+
| | Packets | | Packets | |
| Cache |-------->| ROOT |--------->|Keyword |
| KNS | | KNS | | Table |
| Server|<--------| Server|<---------| |
| | 리소스 | | 리소스 | |
+-------+ +-------+ +--------+

참고) Packets은 유니코드의 키워드 뿐만 아니라 로케일 및 프로토콜의 형태를 포함한다.
리졸버를 통해 전달된 패킷은 사용 언어에 대한 정보를 담고 있다. 따라서 해당 로케일에 대해 권한을 가지는 서버의 주소로 문자열을 전달한다.

권한을 가지는 서버(Root 서버)에서는 관리하고 있는 키워드 테이블 중에서 전달된 문자열과 일치하는 키워드가 존재하는 지에 대한 여부를 판단하고 일치하는 경우 리소스정보를 리턴한다.

키워드 네임서버는 키워드에 대해서 다음과 같은 질의 순서를 따른다.

[1] 현재 관리하고 있는 캐쉬에서 키워드와 일치하는 것이 있는 지 검색 한다. 존재할 경우 키워드에 대한 리소스 정보를 알려주고 존재하지 않을 경우 루트서버 참조를 요청한다.

[2] Root Server는 요청된 키워드에 대한 리소스 정보를 리턴한다.
일치하는 정보가 존재하지 않을 경우 "NOT FOUND"로 처리한다.

6.4 캐쉬서버와 루트서버
캐쉬서버는 별도의 시스템이 아니며 단지 권한을 가지는 키워드 zone파일이 없는 KNS를 캐쉬서버라 한다. 이것은 한 번 질의된 키워드에 대한 응답 정보를 정해진 시간동안 캐쉬하게 되며 이 시간동안 같은 키워드에 요청에 대해서는 직접 응답을 해준다. 단 권한을 가지는 서버로 부터의 응답을 나타내는 플래그는 빠져있게 된다.
만약 캐쉬되어 있지 않은 키워드에 대한 요청이 있다면 루트서버에 해당 키워드를 질의하게 된다.

6.5 응용 프로그램에서의 이용
현재 인터넷 기반의 응용 프로그램은 많은 종류가 있다. 이렇게 다양한 형태의 응용 프로그램마다 요구하는 키워드 네임에 대한 리턴값이 조금씩 다르다. 웹 브라우져의 경우, 요청한 키워드 네임에 대한 응답으로서 URL을 기대할 것이다. 메일 클라이언트라면, 키워드네임 입력에 실제 E-mail Address가 응답되어야 한다. 이것은 같은 키워드 네임에 대해서 응용 프로그램에 따라 다른 식별 인자를 기대한다 것을 뜻한다. 멀지 않은 미래에, 우리가 사용하는 일반 전화기에서 "키워드 네임"을 말하면 해당하는 전화번호가 응답되어 전화기가 자동으로 전화를 걸어주는 서비스가 나타날 지도 모른다. 우리는 이 모든 것을 생각한 시스템을 고안 하여야 한다.

위와 같은 요구조건을 충족시키기 위해서는, 키워드 네임 시스템은 정보 그룹과 매핑 되어야 한다. 그리고 이러한 정보들은 지금 사용되고 있는 응용프로그램, 그리고 미래에 사용되어질 응용프로그램에서 손쉽게 이용할수 있도록 확장을 고려하여 구축되어야 한다.

키워드 -+- Applicaton1 - Application1 해당 값
+- Applicaton2 - Application2 해당 값
+- Applicaton3 - Application3 해당 값

예) 넷피아 -+- 웹브라우져 - www.netpia.com
+- 뉴스클라이언트 - news.netpia.com
+- 메일클라이언트 - webmaster@netpia.com
+- Telnet 클라이언트 - telnet.netpia.com
+- FTPt 클라이언트 - ftp.netpia.com
+- 전화번호 - +82 2 3665 0123

6.6 국제화에 대한 고려

키워드 네임 시스템은 영어권만을 지원하기 위한 서비스가 아니다.
국제적인 서비스를 지원하기 위해 다양한 언어를 지원하여야 할 것이다. 현재까지 국제화된 서비스를 지원하기 위해서 인코딩 방법에 있어서 유니코드를 보통 사용하고 있으나, 키워드 네임 시스템은 유니코드 뿐만 아니라 각 나라의 로컬코드도 모두 지원하여 좀더 확장성 있는 서비스가 되어야 할것이다.

또한 키워드 서비스는 로컬 서비스 기반이 되어야 할것이다. 해당 로컬에서만이 가장 잘 법리적으로 지원할수 있을 것이다. 키워드 네임 시스템은 단지 기술만이 아닌 법리적인 부분과 함께 발전되는 서비스이기 때문에 이부분을 고려하지 않을 수 없다.

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.