INTERNET-DRAFT JH. BAE
November 21, 2001 CH. LEE
Expires May 21, 2002 Netpia dot Com
Native Language Internet Address Service (NLIAS)
draft-jhbae-nliasa-00.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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May, 2002.
Copyright Notice
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 (multilingual.com)
4) Full I18N Domain Name (multilingual.multilingual)
5) Native Language Internet Address (multilingual keyword)
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.
Netpia.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 "seoulsichung.go.kr", the Native Language Internet
Address "seoulsichung" (City hall of Seoul), itself identifies the
governmental organization. As an another example, in
"seouldaehackyo.ac.kr", the Native Language Internet Address, since
"seouldaehackyo" (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) user friendliness
2) consistency
3) extensibility
4) stability
5) recognizability
6) universal validity
Service methods are as follows:
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 be pursued.
[2] Native Language Internet Address Service can provide the basic IP
Address in no time. Otherwise, the DNS should be queried.
[3] The response from the same Native Language Internet Address should
be same regardless of the server type whether it is a cache server
or a root server.
[4] Cache server should not respond with old data for those query.
[5] Protocol should not depend on some specific character sets.
[6] Unique Native Language Internet Address for each language
(character set) should be serviced.
JH BAE & PJ LEE [Page 7]
Internet-Draft NLIAS November 2001
5.2 Requirement for the Internationalization
[1] The character set used in the service should be extended from the
Unicode.
[2] Protocol should do the Name Preparation for the Native Language
Internet Address before the service.
[3] Conflicts on Native Language Internet Address should be reduced by
Name Preparation.
[4] For the case mapping, the upper case letters should be converted
to the lower case ones since most user use lower case letters.
[5] Service should be based on the user's language.
5.3 Requirement for the service administration
[1] Service should be restricted to 1:1 match.
[2] Native Language Internet Address Table should be easily modifiable
[3] Native Language Internet Address System should not give any
influence on the traffic of the DNS system.
[4] Native Language Internet Address should be maintained according to
the character set. No two different character sets can share the
same table. The character sets means the extension of Unicode.
[5] Native Language Internet Address has n:1 correspondence with the
Internet Resource. Internet Resource means the information table
for the Native Language Internet Address.
[6] In a given Native Language Internet Address table, the Native
Language Internet Address should be unique. The same Native
Language Internet Address can be in another Native Language
Internet Address table even if the Native Language Internet
Address implies the same meaning.
[7] The categorization of the table is defined by that of Unicode.
[8] A Native Language Internet Address in a given table is
case-insensitive. For example, "abc" and "ABC" cannot exist in the
same table. If both exist in the same table, one of them is
ignored.
6. Structural Overview
6.1 Interoperable view
A B
+------------+ +---------+ +--------+
| | Query | | Query | |
| Individual |--------->| NLIAS |--------->| NLIAS |
| User |<---------| Servers |<---------| Root |
| | Resource | at ISP | Resource | Server |
| | | | | |
+------------+ +---------+ +--------+
JH BAE & PJ LEE [Page 8]
Internet-Draft NLIAS November 2001
When the user types in the multi-lingual Native Language Internet
Address to the application, the Native Language Internet Address will
be converted to the Unicode character string and then transmitted to
the Native Language Internet Address Server, say A. Native Language
Internet Address server A forwards the query to one of many root
Native Language Internet Address Servers, say B.
The corresponding root server B will respond with the resource by
identifying the character set string based on the unicode. After this,
Native Language Internet Address Server A caches the result so that A
can respond for the the subsequent query for this Native Language
Internet Address. The query should include at least the following
information.
[1] Native Language Internet Address
[2] Resource Information (application information)
[3] Language Information
6.2 Client Side
Local Foreign
+-------------+ Local Code +----------+ Unicode | +---------+
| | String | | String | | |
| User |------------>| Resolver |------------|-->| NLIAS |
| Application |<------------| |<-----------|---| Servers |
| | Resource | | Resource | | |
+-------------+ +----------+ | +---------+
The end user application should be changed to accommodate the
internationalized native Native Language Internet Address service.
In other words, the resolver should take into account the multilingual
characters. This includes the locale information of the client and the
queried protocol information (ex: http, ftp, irc) as well as the
encoding of the Native Language Internet Address itself.
The definitions on character encoding schemes are defined in Unicode
Technical Report 17.
6.3 Server Side
+-------------+ +-------------+ +-----------+
| | Packets | | Packets | |
| Cache |------------>| ROOT |------------>| Native |
| NLIAS | | NLIAS | | Language |
| Server |<------------| Server |<------------| Internet |
| | | | | Address |
| | | | | Table |
| | Resource | | Resource | |
+-------------+ +-------------+ +-----------+
JH BAE & PJ LEE [Page 9]
Internet-Draft NLIAS November 2001
Note) Packets should include not only the unicode Native Language
Internet Address but also the locale and the type of the protocol.
The packet transmitted by the resolver includes the information about
the language used by a user or an application. Therefore, it transmits
the query string to the authoritative server for the corresponding
locale. The authoritative server (Root server) searches a Native
Language Internet Address table for the matching string and returns
the resource information if exists.
Native Language Internet Address Server follows these steps for the
Native Language Internet Address.
[1] It searches the currently maintained caches; If a matched resource
is found, it returns the resource information. Otherwise, it asks
for the root server query.
[2] Root Server returns the resource information for the queried
Native Language Internet Address. If no matching resource is found,
"NOT FOUND" will be returned instead.
6.4 Cache Server and Root Server
Cache Server refers a NLIAS server with no authority on the Native
Language Internet Address zone file and does not refer to a separate
system. This server caches the response information for some finite
time and responds directly to the same Native Language Internet Address
query. But it turns off the flag which indicates the response comes
from the authorative server. If the queried Native Language Internet
Address is not cached, it queries to the root server.
6.5 Usage in application programs.
There are many Internet applications. Each of these applications
require somewhat different return values for the Native Language
Internet Address. For the web browser, the expected result is an URL.
For the mail client, an e-mail address should be returned for the
Native Language Internet Address queries. This means that each
application may require different identifiers for the same Native
Language Internet Address. Soon there may be some telephony system
which dials up automatically just by saying the "Native Language
Internet Address". NLIAS should be designed to accommodate these
applications.
In order to satisfy these requirements, Native Language Internet
Address System should be mapped to an information group and the
information groups should be designed to be easily extended for
the future applications as well as the existing applications.
Native Language Internet Address -+- Applicaton1 - Application1 value
+- Applicaton2 - Application2 value
+- Applicaton3 - Application3 value
JH BAE & PJ LEE [Page 10]
Internet-Draft NLIAS November 2001
ex) Netpia -+- Web Browser - www.netpia.com
+- News Client - news.netpia.com
+- Mail Client - webmaster@netpia.com
+- Telnet Cleint - telnet.netpia.com
+- FTP Clent - ftp.netpia.com
+- Phone - +82 2 3665 0123
6.6 Consideration on Internationalization
Native Language Internet Address System is not limited to be serviced
on English speaking regions. Various languages should be supported
for the international service. Until now, Unicode is used as an
encoding scheme to support the international service so far, but the
Native Language Internet Address System should support the local
regional codes so that it can be more extensible. Also Native Language
Internet Address Service should be based on the local service. It can
be supported best in the corresponding local region by the traditional
trademark principles. Native Language Internet Address System should
consider the legal aspect since the legal issues as well as the
technical issues must be developed.
7. Conclusion
As mentioned above, Native Language Internet Address Service should be
another connection service that makes it easier to type and memorize
the various resources without any modification nor change on the
existing service.
8. Author's Address
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
Changhum Lee
Netpia.com, Inc.
35-1, Youngdeungpo-Dong 8-ga, Youngdeungpo-Gu Seoul, Korea 150-038
Tel : +82-2-2165-3051
Fax : +82-2-668-4913
E-mail: chang@netpia.com
JH BAE & PJ LEE [Page 11]
Internet-Draft NLIAS November 2001
9. definition
[1] LDH : Letters, Digits, and Hyphen
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.
[Alvestrand] "Definitions for talking about directories".
draft-alvestrand-directory-defs-02.txt.
April 2001, H. Alvestrand.
[Klensin1] "Role of the Domain Name System".
draft-klensin-dns-role-01.txt.
May 2001, J. Klensin.
[Klensin2] "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
[Mealling] "Service Lookup System".
draft-mealling-sls-00.txt.
July 2001, M. Mealling and L. Daigle.
[Popp] "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.
JH BAE & PJ LEE [Page 12]