INTERNET-DRAFT Y. Arrouye
February 15, 2002 RealNames Corp.
Expires August 15, 2002 T. W. Tan
National University of Singapore
X. Lee
Chinese Academy of Sciences & CNNIC
Keywords Systems - Definition and Requirements
draft-arrouye-keywords-reqs-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
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
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The DNS (Domain Name System), which was designed as a network
resource naming layer, is not able to serve today's Internet users
naming needs anymore. Attempts to change the DNS to adapt to those
needs, such as the IDN (Internationalized Domain Name) IETF effort,
are not only proving themselves unsatisfactory in many ways, they are
also limited by the nature of DNS itself. There is now strong
consensus that the solution for naming for the Internet requires
layers above DNS. For example, John Klensin has advocated a multi-
layered model that undertakes to address the naming needs of the
modern Internet. In Klensin's model, the layer immediately above DNS
is fully multilingual and user-friendly. It is expected that this
layer will support a variety of distinct services. This document
Arrouye and Tan [Page 1]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
presents the requirements of one class of naming service called
Keywords systems, of which there are several deployed today. These
requirements are presented from the perspective of Internet users,
for whom there exists no satisfactory standard naming system.
1. Introduction
The Internet has evolved from a simple interconnection of networks to
a global infrastructure supporting academic, personal, governmental,
and commercial communications. As a result, the Internet's main
naming system, the DNS, has seen its use change dramatically. As the
number of names in demand has increased, so has the realization that
there is a profound mismatch between a name meant to be used by
humans and one meant to be used by applications. Because they have
been the only names available for use on the Internet, domain names
could not remain simply resource names, but rather were pushed to
became the labels that every Internet user would ideally associate
with the content they sought to access. That push has not happened
smoothly. Attempts to change the nature of DNS names by
internationalizing them do not solve the main problem of the
awkwardness of DNS names in a versatile, multilingual, human-friendly
naming scheme for the global Internet.
As result of the apparent inadequacy of approaches that try to
improve the ability of the DNS to serve as a universal, human-
friendly naming scheme, there is now strong consensus for
establishing a new layer of naming on top of the DNS [DNSROLE,
DNSSEARCH]. This new layer will allow the Internet community to
redefine naming in light of actual needs, without having to change
the DNS or rely on its evolution. The community stresses the
necessity for the new layer to go beyond the needs of the Domain Name
System to realize an architecture capable of accommodating diverse
services, with separate ownerships, different scopes and distinct
operating models.
One of the operating and addressing models proposed as a component of
this new layer is Keywords systems. These systems offer a
multilingual naming layer that is human-friendly and simple to use.
Many Keywords systems that offer similar user experiences are in
existence today: RealNames, worldwide; CNNIC, in China; 3721, in
China; TWNIC in Taiwan; Netpia, in Korea; Nipa, in Thailand, and AOL,
within its own network. The proliferation of Keywords systems in the
Asia-Pacific region emphasizes the DNS's lack of support for non-
Latin scripts.
This document presents the requirements that define Keywords systems
that will be able to interoperate and expand their usefulness.
Arrouye and Tan [Page 2]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
The goals of this document are:
1. To present a clear list of Keywords requirements.
2. To document the Keywords user experience. This defines how
Keywords are being and should be used by Internet users.
3. To document properties of Keywords systems or Keywords objects
that are deemed useful in every Keywords system.
4. To provide a framework for discussion of Keywords systems and
their standardization.
In this document, the terms Keyword or Keyword name have the same
meaning, which is the name of a Keyword. The term Keyword object, or
Keyword resource descriptor, refers to a more complex object
containing properties, or facets, of which the Keyword name is one.
The Keyword object is described in detail in this document.
The definition of terms related to internationalization are those
introduced in [I18NTERMS].
2. User Requirements that are Met by Keyword Systems
Keywords systems should be architected to meet user expectations. The
industry generally agrees that the following are the basic
requirements of any successful Keywords system.
2.1. Unique Names and Identities
The Keyword name is the only element of the Keyword object that the
users manipulate. In order for Keywords to function as an effective
addressing system (see Direct Navigation Using Keywords), a name must
be associated with only one destination in a given context (cf.
context below).
The importance of the uniqueness of the names is reinforced by the
need to support the notion of online identity. One's identity needs
to be clearly and unambiguously defined, and thus unique.
2.2. Above DNS
The DNS in its current form cannot accommodate the Internet's current
naming requirements. Neither can it be changed significantly.
Keywords systems must exist separately from the DNS to offer
applications an independent naming interface. The common view of DNS
and other addressing system is to place the low level systems below
others, so DNS is viewed as above IP addresses, and Keywords systems
Arrouye and Tan [Page 3]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
would be viewed as above DNS and URIs.
2.3. Multilingual
Keywords must be available in all languages and scripts. Because
Keywords systems are implemented electronically, and because it is
agreed that it is practical to use a single encoding for the names,
the languages and scripts that Keywords must support are those of
that encoding that will be picked.
2.4. Context-Based
While the name is the most important element of a Keyword object, it
benefits from being supplemented by other attributes such as country,
language, type of application (also called service type in [SLS] and
[KLS]), etc. These attributes are also referred to as facets. (See
"Benefits of Direct Navigation" for a further discussion of context.)
2.5. Applicable Across Multiple Applications
Keywords must function in a broad variety of applications and
devices, such as the World Wide Web, mobile phones, e-mail, etc.
2.6. Multiple Interoperable Namespaces
Due to the complexities of languages, local usage and policy
differences in countries or application domains, it is neither
feasible nor practical to implement a single, worldwide Keywords
system. A differentiated, interoperable federation of Keywords
systems will provide the flexibility and depth needed. These Keywords
systems will be unified by a single resolution protocol that will
guarantee interoperability of the Keywords systems for applications.
3. Keywords User Experiences
There are two common user experiences associated with Keywords. The
most common one, and the one that makes Keywords appealing, is
navigation. The second one is discovery. These experiences are
described below.
3.1. Direct Navigation Using Keywords
The goal of all Keywords systems is to make it as simple as possible
to reach a given physical destination by using a simple human-
friendly name. A physical destination is anything that can be
described by a URI [RFC2396], so for example a Web page, an e-mail
address, or a WAP page on a mobile phone are all physical
destinations. Internet destinations are one kind of physical
Arrouye and Tan [Page 4]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
destinations.
The typical experience of a user of a Keywords system is as follows:
1. The user enters a Keyword in her own language in her application,
and eventually selects an action (e.g. "go" in a Web browser, or
simply hitting the "enter" key).
2. The application transparently uses a Keywords system to map the
Keyword to a physical address that is appropriate to its domain
(e.g. a Web address for a Web browser, an e-mail address for a
mail user agent, etc.).
3. The physical address that has just been obtained is used to
perform the user-specified action (e.g. load a Web page, send e-
mail to a specific mailbox, etc.).
This is called direct navigation, as it lets a user go directly to a
destination using this simple name.
3.1.1. Benefits of Direct Navigation
Direct navigation is what makes Keywords systems appealing to users
as an addressing system. Keywords systems are designed with the
objective of providing the best user experience: intuitive names that
deliver expected results. This section looks at a few benefits of
Keyword systems.
1. Users see Keywords as actual Internet addresses, and they work
just like any other addressing system. Contrarily to traditional
Internet addresses, they are easy to remember. The critical part
of the Keywords navigation experience is in the second step, where
the application uses the Keyword input by the user to obtain a
physical address. This can be done today using proprietary
protocols or CNRP (Common Name Resolution protocol) [CNRP],
although it is likely that if Keywords systems are deployed on a
large scale a more compact protocol will be designed. What is
important to understand is how the application uses the Keyword as
well as other data to make a query to a Keywords system.
2. A given Keyword object may contain different physical addresses
for different applications, which is akin to saying that Keyword
objects are identified by a combination of name and application
type. That application type (also called service type in [SLS] and
[KLS]) makes up some of the context that is passed to a Keywords
system, along with a name (also part of that context), in order to
identify a given Keyword object. Whenever the context is fully
specified, a Keywords system will return at most one matching
Arrouye and Tan [Page 5]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
Keyword object. This notion of context is key to the resolution of
a Keyword query into a physical address.
3. The more context is available, the more powerful a Keywords system
can be, and the better user experience it can provide. For
example, just by introducing the language as an element of
context, one can then use a global name like BMW, or Coca-Cola,
and access content in the appropriate language. Obviously, such a
language facet contributes to the human-friendliness of the system
by allowing not only the Keyword names, but also the content they
refer to, to be in the user's language. Such a language context is
also quite easy to obtain, since operating systems as well as
applications already support the notion of a user-selected
language (such as one's browser language setting) or locale.
Note that direct navigation does not mean that the only thing that
can happen to a Keywords user is either to get to a destination or
get nowhere. A Keywords service, when there is no matching Keyword
object for the user's query, may return a list of approximate
matches. It is up to the application to use that list and interact
with the user as needed to pick between these matches if desired.
Applications may also choose alternate behaviors such as using a
search engine, or combining the approximate matches with other
heuristics, etc...
3.1.2. Definition of the Context
It is very tempting to make a long list of desirable facets of a
Keyword object. Location and industry category, for example, are two
properties that are often mentioned, and more facets are regularly
offered for consideration.
An important lesson learned from operating Keywords system so far is
that it is very difficult to ask users to supply context that is not
already available to the application. Not only does this usually
bring up user interface issues, it changes the user experience from a
"type the name, get what you want" to a less direct, much more
painful experience that drives users away from the system. It is also
worth noting that asking for determination after the user has input a
partial context that can match a number of Keyword objects, has the
same effect of breaking the user experience and discouraging her. The
key to context information in a Keywords system is that context must
be implicit (i.e. known a priori to the application) in order to
offer a good user experience.
As a result, one must be very careful in introducing facets that need
to be part of the context. On the other hand, one should always ask
the registrant of a Keyword to provide as many facets as possible, in
Arrouye and Tan [Page 6]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
order to be able to use them later, as applications improve and
become able to supply meaningful values for those facets as part of a
query to a Keywords system.
3.1.3. Manipulation of the Context
While the user should only be required to enter a name in order to
reach a destination, it is desirable that the hidden parts of the
context can be manipulated by the user. This is usually done by
providing settings that can be used to do these manipulations. For
example, a Web browser typically offers a way to set language
preferences, from which the language context can be drawn.
3.2. Discovery of Keywords
We have so far described the experience of a user who uses a Keyword
in order to get to a physical address. There is also a need for users
to discover Keywords. Discovery may happen either when a user is not
able to supply all the facets necessary to make a single
determination, or when she only has partial data such as a few words
of a multi-word Keyword.
Discovery services are valuable because they offer users a way to
browse a Keywords namespace and explore its content. They need to be
separate from direct navigation in order to preserve the directness
of the navigation experience. It is however possible to offer
discovery as a fallback after a failed navigation experience, as long
as the two experiences are clearly distinct.
3.3. Other Variations
In some environments, such as mobile phones, typing a full Keyword
may prove cumbersome. It is thus a good experience, in these
environments, to support some form of automatic completion of partial
Keywords. The navigation may not be direct then, because confirmation
from the user is needed, but the overall experience of using Keywords
is improved because of the diminished pain factor in entering the
names.
4. The Keyword Object
We have so far described the Keywords user experience and looked at
two of its aspects. We have said that Keywords system contain
Keywords objects that contain a number of facets. This section
describes facets that make up a Keyword object. There are two kinds
of facets, depending on whether they are used as part of the context
or not:
Arrouye and Tan [Page 7]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
1. Key facets are part of the context that is necessary to establish
a one-to-one mapping between context and a physical address. The
name and the service type are good example of such facets.
2. Informational facets carry information that is useful but not
required as part of the context. A description of a Keyword is a
good example of such a facet.
Key facets are always required. Some informational facets may be
optional, and others may be required. In this section, the facets are
listed with an indication of their kind.
One should note that some facets may make sense for some service
types and not for others. The categorization of facets below is
intended to ensure that the facets that are key are required for all
service types. Also, it may be interesting to allow optional context
facets, whose presence can improve the user experience.
4.1. Name (Key Facet)
The name is the most visible part of a Keyword system, as it is what
users see, remember, and then use in order to navigate. It is also
what defines one's online identity.
It is widely agreed that DNS and other Web-addressing systems (such
as the URI) cannot create human-friendly names. To be human-friendly,
a name must satisfy a number of conditions. It should be easy to
remember. Familiar brand names should be transferable to the
Internet naming system with no change if possible. Names should be
available for the whole user population, and should be available in a
user's native languages and scripts. Finally, the syntax of names
should be flexible enough to allow for desirable names. One will note
that that lack of syntax not only makes the names easier to remember
and use, it also opens the door to the use of Keywords through voice
recognition technology available today.
Issues pertaining to names are discussed further in the "Multilingual
Support" section.
While it is useful to have syntax free names, some restrictions can
be placed on name availability in order to preserve existing
namespaces. For instance, if a Keywords system offers a transparent
interface to namespaces like DNS, ENUM, etc... it can prevent the
subscription of Keywords that follow the syntax of these namespaces
in order to avoid confusion between the different namespaces.
4.2. Service Type (Key Facet)
Arrouye and Tan [Page 8]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
The service type is used to describe a class of applications that
provide a given service to users. For example, tentative service
types are "web," "e-mail," "mobile web," and even "dns" or "phone."
The service type is a primary mechanism to support the reuse of one
given name to denote different bits of information (which are
accessed through a given physical address).
4.3. Service Provider (Key Facet)
Because there are many different Keywords systems in existence, there
is a need to be able to refer to them to determine which system a
Keyword belongs too. That is the purpose of a service provider facet.
The facet is part of the context that defines the uniqueness of a
Keyword, allowing distinct Keywords provider to have their own
Keyword object for a given Keyword.
4.4. Language (Key Facet)
The language facet denotes the language of the Keyword. It can be
used, for example, to enable language-specific rules of
normalization, or simply to determine how to display a CJK name made
of unified Han characters.
There are many standards or would-be standards for the identification
of languages. The IETF standard for languages is defined in
[RFC3066], which obsoletes [RFC1766], still cited by many protocols
and IETF work documents. Also note that [RFC2277] says that language
tagging in IETF protocols should be done using this standard. The
biggest advantage of using language tags as defined in [RFC1766] is
that existing protocols and applications support them, which makes it
easy to obtain a language facet value as part of the Keyword request
context without user interaction.
An oft-cited categorization of languages is the one produced by SIL
International. Known as the Ethnologue [ETHNOLOGUE] their work
categorizes and uniquely identifies more than 6,700 languages used in
228 countries. There have been proposals to make the Ethnologue
categorization available as an Internet categorization, and one could
indeed use i-sil-xxx to refer to the Ethnologue language code xxx in
perfect conformance with [RFC1766], but today's applications are not
aware of Ethnologue language codes.
4.5. Content-Language (Key Facet)
The content-language facet describes the language of the content that
is accessed through the physical address. For instance, if the
Keyword named "Deutsche Telekom" has the Web physical address
http://www.telekom.de/dtag/ipl2e/cda/t1/ then the content language
Arrouye and Tan [Page 9]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
should be English since that is the language of the content.
This facet can be used for language negotiation, which is supported
in some protocols already. he facet uses the same standard as the
language facet to identify the language.
4.6. Country (Key Facet)
The country facet refers to the country for which the content
accessed through the physical address is intended. Countries are
indicated by using country codes from ISO 3166 [ISO3166]. ISO 3166 is
a three-part standard. The part relevant to current countries is ISO
3166-1. It standardizes names of countries and associates them with 2
and 3 letter codes referred to as alpha-2 and alpha-3, respectively.
Internet usage, primarily stemming from RFC3066, is to use the
alpha-2 variant.
Applications are only starting to support separation between language
and countries. Such a separation is very important, because it
enables to offer a good service to ethnic groups in a given location.
When language and country are mixed, only the populations large
enough to have a recognized dialect in that country can be serviced.
In order to provide backwards compatibility, it is permissible to use
the country component of an RFC3066 language tag in order to
determine the value of the country facet.
4.7. Physical Address (Informational Facet, Required)
This facet contains the address that the Keyword overlays, i.e. the
real name of the data that are accessed using the Keyword. It is
proposed that this facet always be a URI, which may require the
definition of new URI schemes for existing addressing systems. The
URI was designed as an extensible addressing system, and it would be
nice to take advantage of its properties for the physical addressing
component of Keywords systems.
4.8. Description (Informational Facet)
While key facets are necessary for querying a Keywords system,
informational facets are useful when displaying Keywords in listings,
such as the ones that a discovery service may provide. The
description facets describes a Keyword in a few sentences, in such a
way that its meaning is obvious to a reader.
There must be one description for the language of the Keyword, i.e.
if the Keyword is associated to Korean content, there must be a
Korean description. It may be desirable to support additional
descriptions in other languages.
Arrouye and Tan [Page 10]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
4.9. Location (Informational Facet)
This facet is often mentioned as something that is very useful. One
of the main problem is to decide what kind of location to use. Valid
suggestions include: a system like country, province, zip code, or a
subset thereof; ISO 3166-2; latitude, longitude, altitude; ECEF
(Earth-Centered, Earth-Fixed); and probably others. Note that it is
possible to go from one of the fine-grain systems to the coarser-
grain ones, but that the (lack of) availability of mapping tables may
be a factor. It is also possible to support more than one location
notation at the same time.
For applications like mobile phones, the location of the user
relative to cell towers (whose locations on or above Earth are
themselves known) is known by the mobile phone operator and could be
made part of the context. Note that this particular example raises
some privacy issues that the operator or service need to take care
of.
4.10. Category (Informational Facet)
There has been talk of the necessity of having some sort of industry
category facet in the next Internet naming layer, and of making it
part of the facets that determine the uniqueness of records in this
layer. While we agree that such information is useful meta-data that
can be used in a discovery service, there are some problems with
making such a category part of the context:
- Even though one may argue that the categories listed in WIPO's Nice
agreement [WIPO-NICE] are encompassing enough for industry
categories, there is no established standard for non-industry
categories. The development and ratification of such standard is a
very big task in itself.
- Applications do not support categories. If they did, it is doubtful
that a typical user could come to grasp with the big tree of
categories. And if only the top-level classes were to be offered to
users for selections, they would be lost even more since those
classes mix things such as computer software design and animal
grooming. And the fact that our [Ed.: RealNames'] marketing lady
calls us monkeys does not make that really clearer for everyone.
As a consequence of these problems, Keywords systems do not support
such data as a key facet, but only as an informational one.
5. Multilingual Support
Arrouye and Tan [Page 11]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
It is understood that today, the best way to manipulate names for
multiple scripts is to rely on encoding those names using Unicode
[UNICODE]. This is the proposed encoding of names for Keywords
system. References to characters or character sequences in this
document are made using Unicode.
5.1. Human-friendliness can also be achieved by helping users get the
desired result through some normalization of the names that are used.
For example, it is desirable to treat the sequence <U+0065 LATIN
SMALL LETTER e><U+0301 COMBINING ACUTE ACCENT> as equivalent as
<U+00E9 LATIN SMALL LETTER E WITH ACUTE> (the former sequence being a
canonical decomposition of the second one [UTR15]). But other
features of human-friendliness, for example respecting alternate
spelling rules for German, or handling traditional versus simplified
Chinese writing systems, are not always understood, or simply agreed
on. There is a need to define the requirements necessary for the
interoperability of Keywords systems, and what features can be used
to distinguish different services between each other. These issues
are discussed at a further point in this document.
Note that the discussion of normalization above is not a discussion
of Unicode normalization. It is a discussion of string normalization
that may use Unicode normalization as a tool. A better term may be
string preparation, and it would be desirable to use the framework
defined in [STRINGPREP] for such a normalization, if possible. Note
that there may be a need for different Stringprep profiles for
different languages, something that Keywords systems can support
thanks to their rich set of facets.
Different names normalization on top of the default normalization may
be an interesting service differentiator.
5.2. Traditional and Simplified Chinese
The Chinese language can be written in two forms: Simplified Chinese
(SC), used in the People's Republic of China (PRC) and Singapore; and
Traditional Chinese (TC) used in Taiwan, Hong Kong, Macau, and by
most Chinese people overseas. One of the issues that face naming
systems is that one name registered in one form may be used by users
writing the other form. Also, mixed form names may be an issue for
the same reason.
A common fallacy is to believe that there is a straightforward 1-to-1
mapping between the forms. Some of the Chinese characters of one form
have 1-to-many mappings, others have many-to-1 mappings, and others,
when in groups, cannot be easily converted without risking changes in
the meaning of the converted sequence. Also, some characters are used
in both traditional and simplified Chinese. As a result, the problem
Arrouye and Tan [Page 12]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
of matching Chinese input to registered Chinese names is complex.
However, Keywords systems may be able to offer a better solution than
existing systems to the problem of handling traditional and
simplified Chinese names.
First of all, Keywords systems fully support the notions of country
and language. Because the choice of using traditional and simplified
Chinese was dictated by countries, that support will help solving
that problem. For example, one common objection to mapping between
Traditional and Simplified Chinese forms is that the Unicode code
points for Traditional Chinese are also used in Japanese and Korean.
Having the language available prevents unwanted alteration of names
in these languages. Also, the availability of the country could lead
to different mapping rules agreeable to that particular country.
6. Conclusion
We have presented the requirements for Keywords systems, the Keywords
user experience, as well as some design and architecture
considerations.
Keywords systems, which are already deployed worldwide, will
represent an important component of the next Internet naming
architecture.
7. References
[CNRP] N. Popp, M. Mealling, and M. Moseley, Common Name Resolution
Protocol (CNRP), draft-ietf-cnrp-10.txt, June 2001.
[CONTLANG] H. Alvestrand, Content Language Headers, draft-alvestrand-
content-language-02.txt, May 2001.
[DNSROLE] J. Klensin, Role of the Domain Name System, draft-klensin-
dns-role-01.txt, May 2001.
[DNSSEARCH] J. Klensin, A Search-based access model for the DNS,
draft-klensin-dns-search-01.txt, July 2001.
[ETHNOLOGUE] SIL International, The Ethnologue,
http://www.ethnologue.org/.
[I18NTERMS] P. Hoffman, Terminology Used in Internationalization in
the IETF, draft-hoffman-i18n-terms-05.txt, January 2002.
[IDNWG] IETF IDN Working group,
http://www.ietf.org/html.charters/idn-charter.html.
Arrouye and Tan [Page 13]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
[ISO3166] ISO 3166 Maintenance Agency, ISO 3166 Standard,
http://www.din.de/gremien/nas/nabd/iso3166ma/.
[KLS] Y. Arrouye, V. Parikh, and N. Popp, Keyword Lookup Systems As a
Class of Naming Systems, draft-arrouye-kls-00.txt, August 2001.
[NAMEPREP] P. Hoffman and M. Blanchet, Stringprep Profile for
Internationalized Domain Name, draft-ietf-idn-nameprep-07.txt,
January 2002.
[PROVREGWG] IETF Provreg Working Group,
http://www.ietf.org/html.charters/provreg-charter.html.
[RFC1766] H. Alvestrand, Tags for the Identification of Languages,
RFC 1766, March 1995.
[RFC2277] H. Alvestrand, IETF Policy on Character Sets and Languages,
RFC 2277, January 1998.
[RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource
Identifiers (URI): Generic Syntax, RFC 2396, August 1998.
[RFC2916] P. Faltstrom, E.164 number and DNS, RFC 2916, September
2000.
[RFC3066] H. Alvestrand, Tags for the Identification of Languages,
RFC 1766, January 2001.
[SLS] M. Mealling and L. Daigle, Service Lookup System (SLS), draft-
mealling-sls-00.txt, July 2001.
[STRINGPREP] P. Hoffman and M. Blanchet, Preparation of
Internationalized Strings ("stringprep"), draft-hoffman-
stringprep-00.txt, Septermber 2001.
[UAX15] M. Davis and M. Duerst, Unicode Standard Annex #15: Unicode
Normalization Forms, March 2001
(http://www.unicode.org/reports/tr15/).
[UNICODE] The Unicode Consortium, The Unicode Standard, Version 3.0,
Addison-Wesley, Reading, MA, January 2000 (ISBN 0-201-61633-5).
Amended by the Unicode Standard Annex #27: Unicode 3.1, May 2001
(http://www.unicode.org/reports/tr27/), and by the Unicode Standard
Annex #28: Unicode 3.2, December 2001
(http://www.unicode.org/reports/tr28/).
[WIPO-NICE] World Intellectual Property Organization, "Nice Agreement
concerning the International Classification of Goods and Services for
Arrouye and Tan [Page 14]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
the Purposes of the Registration of Mark," June 1957.
http://classifications.wipo.int/fulltext/nice/ennnic.htm.
Authors' Addresses
Yves Arrouye
RealNames Corporation
150 Shoreline Drive
Redwood City, CA 94065
Phone: +1 (650) 486-5503
E-mail: yves@realnames.com
Tan Tin Wee
Bioinformatics Centre
National University of Singapore
10 Kent Ridge Crescent
Singapore 119260
E-mail: tinwee@pobox.org.sg
Xiaodong Lee
Chinese Academy of Sciences & China Network Information Center
4 South 4th Street
ZhongGuanCun
Beijing
P.R. China 100080
Phone: +86 10 62619750 3020
E-mail: lee@cnnic.net.cn
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Arrouye and Tan [Page 15]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arrouye and Tan [Page 16]