idnits 2.17.1
draft-arrouye-kls-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document is more than 15 pages and seems to lack a Table of Contents.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There are 2 instances of too long lines in the document, the longest one
being 2 characters in excess of 72.
** The abstract seems to contain references ([SLS]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- Couldn't find a document date in the document -- date freshness check
skipped.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-12) exists of draft-ietf-cnrp-10
== Outdated reference: A later version (-05) exists of
draft-klensin-dns-role-01
** Downref: Normative reference to an Informational draft:
draft-klensin-dns-role (ref. 'DNSROLE')
== Outdated reference: A later version (-06) exists of
draft-klensin-dns-search-01
-- Possible downref: Normative reference to a draft: ref. 'DNSSEARCH'
** Obsolete normative reference: RFC 2916 (Obsoleted by RFC 3761)
== Outdated reference: A later version (-02) exists of draft-mealling-sls-00
-- Possible downref: Normative reference to a draft: ref. 'SLS'
Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 INTERNET-DRAFT Y. Arrouye
2 August 1, 2001 V. Parikh
3 Expires February 1, 2002 N. Popp
4 RealNames Corp.
6 Keyword Lookup Systems As a Class of Naming Systems
7 draft-arrouye-kls-00.txt
9 Status of this Memo
11 This document is an Internet-Draft and is in full conformance with
12 all provisions of Section 10 of RFC2026.
14 Internet-Drafts are working documents of the Internet Engineering
15 Task Force (IETF), its areas, and its working groups. Note that other
16 groups may also distribute working documents as Internet-Drafts.
18 Internet-Drafts are draft documents valid for a maximum of six months
19 and may be updated, replaced, or obsoleted by other documents at any
20 time. It is inappropriate to use Internet-Drafts as reference
21 material or to cite them other than as "work in progress."
23 The list of current Internet-Drafts can be accessed at
24 http://www.ietf.org/1id-abstracts.html
26 The list of Internet-Draft Shadow Directories can be accessed at
27 http://www.ietf.org/shadow.html
29 Copyright Notice
31 Copyright (C) The Internet Society (2001). All Rights Reserved.
33 Abstract
35 This document emphasizes the convergence of thinking regarding
36 Internet naming in the industry and the technical community.
38 There is strong consensus for establishing a layer above the current
39 DNS to address some of its current limitations. At the same time, the
40 community stresses the necessity for the new layer to go beyond the
41 sole needs of the domain name system to realize an architecture
42 capable of accommodating diverse services, with separate ownerships,
43 different scopes and distinct operating models. In that context,
44 interoperability is critical.
46 This Internet-Draft introduces critical requirements for supporting
47 multiple namespaces, in particular the crucial need for discovering
48 namespaces across service providers. Acknowledging the direction
49 opened by a reflection on the DNS [DNSROLE, DNSSEARCH] as well as the
50 need to support flexible naming for various services [SLS], we
51 describe the Keywords systems as a unique class of Service Lookup
52 Systems [SLS].
54 1. Introduction
56 During the course of the past few years, a number of companies have
57 looked into providing an easier user interface for Web navigation
58 than that of typing a URI into a browser's address line. Examples of
59 such companies are RealNames (worldwide network), Netword (North
60 America), Netpia (Korea), and 3721 (China).
62 All of these companies recognized the fact that URIs are unwieldy at
63 best for users: they are hard to remember, due to their syntax, and
64 as far as Web users are concerned, the only URIs that they commonly
65 type into a browser are those forms that consist of the sole DNS name
66 of the server they want to contact, eventually preceded by a valid
67 protocol scheme. Therefore, identifiers like "www.ietf.org,"
68 "www.yahoo.com," and others, have replaced URIs in daily interaction
69 with the Web.
71 Unfortunately, even these short names do not address users' needs.
72 For example, while "www.ford.com" does belong to Ford Motor
73 Corporation, it is "www.fordvehicles.com" that shows vehicles of the
74 Ford brand. Not only is it unfortunate that people think of one name
75 ("ford") and need to use another one ("fordvehicles"), but the DNS
76 labels are not user-friendly names: "fordvehicles" has no space
77 between the words, for example.
79 While companies have been very creative in fitting their brand names
80 into DNS labels (as can be seen by the company "Bird & Bird" getting
81 the DNS name "twobirds.com"), if one looks at the Web in general,
82 there is a big disconnect between the DNS labels that are used to
83 identify Web sites, and the actual names by which people refer to
84 these sites, which are typically brand or product names.
86 This should not come as a surprise considering that the role of DNS
87 is to map unique identifiers to network resources, not to give human
88 friendly names to information or services. DNS has been abused to
89 fulfill naming needs on the Web for a few years. It is actually a
90 testimony to the strength of DNS that it has not crumbled under the
91 additional requirements it has been put through.
93 User behavior and expectations are just one part of the problem that
94 DNS was not designed to and cannot be expected to address. In
95 addition, the Internet world is truly multilingual, bringing in a
96 whole new set of names that are used to refer to information and
97 services. People in different parts of the world want to use their
98 own languages and scripts to refer to things, on the Web, in e-mail,
99 on the Internet. So do companies. A Chinese company does not want to
100 offer its Chinese products to its Chinese customers via a URI in
101 Roman Script.
103 Because DNS is the visible tip of the naming iceberg, the one that is
104 already working and freely accessible (obtaining a domain name is
105 pretty easy), people want to add capabilities to support DNS names
106 that are truly multilingual, and the existence of the IETF
107 Internationalized Domain Name (IDN) working group is a recognition of
108 that desire.
110 Unfortunately, a number of limitations of today's domain names still
111 apply to IDNs as they are being considered now. Amongst them, the
112 inability to use a space to separate words, strong limitations in the
113 length of labels, and the lack to carry enough expression power to
114 handle the visual requirements of names in Persian, for example.
116 The technical community has begun to recognize that naming for humans
117 is something that needs to be addressed outside of DNS, because DNS
118 is a system of identifiers for network resources, not a system of
119 easy-to-use names. Companies selling keywords and other friendly
120 names have been the first to address this need. One only needs to be
121 aware of the existence of John Klensin's drafts about the role of DNS
122 and how to extend it by adding other layers [DNSROLE, DNSSEARCH] to
123 acknowledge that this view is becoming a well-regarded one.
125 Keywords systems, which are based on natural language names in native
126 languages, were the first to turn the recognition about the paradigm
127 shift that happened in the use of DNS names into a new product and
128 protocol layer.
130 Their existence has fostered the creation of the Common Name
131 Resolution Protocol [CNRP] in 1999. CNRP was an acknowledgment that
132 users and applications wanted to use simple names to denote arbitrary
133 resources on the Web. CNRP did not address the existence of many
134 namespaces that were task-oriented.
136 SLS builds on this foundation. It recognizes that people primarily
137 use services such as the DNS, the Web, or email, and that those
138 services use names to denote information. Using SLS, and thus CNRP,
139 one can get from human-friendly names to network or information
140 resource identifiers for a number of applications.
142 2. Keyword Systems and Lessons Learned
144 The primary goal of a keyword system is to make it easy for users to
145 refer to things by their common, or human-friendly name in their
146 local language. Keyword systems also take into account what users
147 commonly expect - that the network will have information about them
148 and use that context on their behalf to navigate them to the "best"
149 destinations on the Web based on their query.
151 It is a fact that a given name may refer to different things:
152 "Woolworth" is a dime store in the USA but a high-end clothing store
153 in South Africa; there may be one "Joe's Pizza" per city, or even
154 more; and trademarks of the same name, but different applicability
155 fields, coexist in a given country. Users, however, are typically
156 only interested in giving one name to get some information.
158 What RealNames learned from this is that while it is important for
159 names to co-exist and be differentiated by facets(e.g. country, city,
160 language, ...), it is also important that this differentiation is
161 done transparently for the user wherever possible.
163 Let's look at the RealNames keyword system for example. A Keyword has
164 many facets, amongst them a name, a country, a language, a
165 description, a URI, and a service code. Service codes (also called
166 content codes) differentiate between the "web" and "mobile phone web"
167 for which content is typically formatted differently. Countries let
168 people refer to a global brand such as "Coca-Cola" by using the same
169 name in different places. Language addresses the needs of countries
170 with various ethnic populations, or official languages, to cater to
171 the language requirements of their population. Description is a
172 purely informative property. Finally, through a URI, one can point to
173 the exact physical address associated to a given name in a given
174 context.
176 We've just used the word "context" and it is worth examining it. If
177 names need to be associated to some meta-data to be useful and not
178 fall into the flat namespace trap that the DNS has fallen into with
179 gTLDs like .com, and, if users are going to expect satisfactory
180 results using just names but not all the meta-data when using a
181 keyword, then it is clear that the remaining meta-data must be
182 supplied from the user's context.
184 As namespaces will become more specialized, allowing for more
185 identical names to exist in different dimensions, the reliance on
186 context will increase. As we have operated our Keyword system these
187 past four years, we have found that obtaining more meta-data is a
188 difficult task. It is a formidable chicken and egg situation. If
189 users' applications and devices cannot supply the relevant data, then
190 name buyers will not be willing to supply the appropriate ones when
191 registering keywords. Keyword name buyers will only supply meta-data
192 if they see a benefit. Benefits are derived from applications that
193 perform more efficient navigation based on meta-data. No
194 specification, regardless of how robust it may be, can alter this
195 dynamic by itself. This combination of meta-data requirements and
196 reluctance to provide meta-data cannot be ignored as we lay down the
197 foundation for a new standard.
199 At the same time, once a name buyer uses a Keyword system the
200 importance of meta-data becomes clear and they are willing to provide
201 appropriate meta-data to support the names they buy.
203 However, name buyers are generally unwilling to supply more than a
204 name at the time of use of the system (primarily because they take
205 the rest of context for granted), so the burden of supplying the
206 contextual information falls solely on the application or device.
208 One key to resolving this problem is mining and using whatever
209 context can be supplied. For example, as devices get smarter, they
210 can also supply more context. For example, a Web browser typically
211 knows about the user's language (from its language preferences, which
212 then translate into an HTTP header for language negotiation), and can
213 make a (risky) assumption about the country from the language. But a
214 cellular phone nowadays can also know about the user's location to
215 some reasonable accuracy. The existence of both devices also means
216 that the kind of device is part of the available context.
218 Another lesson from the requirement for context is that not all the
219 properties of a keyword are useful in order to use the keyword as a
220 way to go get some information (through the URI associated to it).
221 The URI, which is what one wants to get, is definitely not one of
222 these properties. Also, in a system where keywords are associated to
223 a description, one does not want to require the description in order
224 to enable direct resolution.
226 In terms of supplying meta-data, the description associated with a
227 keyword in the RealNames system is not necessary for lookups, while
228 it is very useful for displaying entries in a directory of keywords.
229 Some properties, like an industry category, are useful in both cases,
230 but cannot be used today for navigation because of difficulty of
231 establishing their value as part of a user's context.
233 We call unique key the set of properties that are required to match a
234 keyword and get a single result from a lookup. These properties
235 translate into required context if an application wants to offer
236 direct navigation from a name to a destination through a keywords
237 system. Unique keys may differ from one keywords system to another
238 (for example, RealNames uses a few properties while Netword only uses
239 a name today). Unique keys may, and will, change, depending on the
240 sophistication of the devices that are used to access a given
241 service.
243 As unique keys become smarter and able to know more about the context
244 of their uses, more discriminating namespaces can come into existence
245 and proliferate. Today, given the simplicity of the devices we use,
246 keywords systems use short unique keys for the emerging namespaces
247 that Keywords systems are.
249 Because the unique key lets one access a record with other meta-data,
250 it can be used not only to enable applications to fetch a URI and use
251 it, but also to give one a place to store state.
253 3. The Importance of Multiple Namespaces Above DNS
255 A keyword system is an example of a namespace made up of records
256 which consist of the unique keys and other helpful information. This
257 namespace is dedicated to providing keyword-based natural language
258 navigation. We believe that this is only one of many types of
259 namespaces that will emerge as the Internet continues the significant
260 transformation it is now undergoing.
262 Like many in the industry, we believe that the limitations of DNS
263 will be best addressed by facilitating the emergence of many
264 interoperable namespaces. These multiple namespaces will be largely
265 distributed, with distinct owners and administrative rules. In fact,
266 that has already occurred, to the good of Internet users and service
267 providers. We believe the right course is to encourage this
268 innovation, and that industry and the technical community should work
269 together to define a set of standard protocols through which all of
270 these namespaces can interoperate.
272 As the network continues its evolution, namespaces will offer
273 different types of content and information to users and will be based
274 on a continuum of business models. Although a namespace is likely to
275 focus on one or a few types of network resources, it will be
276 necessary for applications to interact with many namespaces at the
277 same time in the course of a user session. Clearly, a flexible,
278 lightweight protocol needs to define and facilitate interaction.
280 This interaction is likely to encompass at the minimum registration,
281 resolution (lookup) and discovery (search) services. Application
282 developers must be able to rely on a common set of protocols for
283 interacting with namespaces both to reduce the burden of adding new
284 services to the network and also to enable users to freely choose
285 between a rich offering of providers.
287 Based on current industry development, it is not difficult to
288 anticipate tomorrow's importance of companies, people, and products
289 namespaces whose services will be delivered to user applications
290 through the network and across multiple devices ranging from desktops
291 to PDAs and data enabled cell phones.
293 Many important instances of namespaces have already appeared in the
294 last few years, and the fast-growing concept of Web services is
295 likely to increase the reliance of user application on these
296 namespaces as a core component. The increased tie and reliance
297 between applications and namespaces accessible through the network
298 exacerbates the need for open standards and interoperability.
300 For example, if ICQ was one of the first major community namespace,
301 Firefly was the first company to identify the need for separate
302 specialized namespaces. Passport and its Hailstorm incarnation will
303 be a namespace for people as network end-points that will not only
304 provide unique identity (email address) to people but also personal
305 context storage, and presence detection. Namespaces for people as
306 network end-points are likely to become fundamental elements of all
307 user-centric applications. Namespaces will likely encompass many
308 aspects of our user experience. Napster was the first P2P music
309 namespace to profoundly impact the way users lookup and discover
310 songs on the network and MusicNet is a more recent attempt to create
311 a commercial music namespace that can be distributed through multiple
312 applications.
314 Other namespaces will be business enablers. UDDI is an industry-wide
315 attempt to create a namespace for small and medium companies to
316 discover each other and conduct business across the Internet and
317 Keywords systems like RealNames are specialized toward human-friendly
318 access to companies, products and services. There will obviously be
319 many more valuable namespaces in the future.
321 Since one cannot and does not want to anticipate any single one of
322 them to dominate, it is important to facilitate the interaction of
323 applications with multiple namespaces through a common sets of
324 protocols accessible across multiple devices and operating systems.
326 4. Requirements Arising From Multiple Independent Namespaces
328 The growing proliferation of many independent namespaces places
329 important constraints and requirements on the standard that will be
330 created. We believe that some of these requirements may have been
331 absent or minimized in previous proposals. Such critical constraints
332 include:
334 - The definition of a mechanism for discovering Namespaces.
336 - The standardization of all core namespace services: resolution
337 (lookup), discovery (search) and registration.
339 - The need to simplify Klensin's layer 2 [DNSROLE] in order to
340 facilitate the adoption of the standard by most client applications
341 and service providers.
343 - The support for different rules of uniqueness and disambiguation
344 across namespaces.
346 The first requirement is about enabling applications to discover all
347 available Namespaces.
349 The second is about service interoperability. In a world of many
350 namespaces, these requirements are straightforward (and the solutions
351 non trivial).
353 The third requirement underlines the need to minimize the definition
354 of the schema that Klensin's layer 2 services must all implement for
355 interoperability. It is mainly driven by the need to simplify client
356 implementations. As we impose more facets on this layer, we impose
357 more burden on application developers and the user-interface
358 (especially considering that as pointed out above, the user context
359 carried by applications today is fairly minimal). This model cannot
360 be successful in practice.
362 Application developers' adoption of the standard is obviously
363 essential since the prospect of increased distribution will be the
364 main driver for namespace owners to implement the standard and make
365 their service interoperable.
367 However, we also recognize that from a service provider standpoint,
368 the complexity of the Klensin's layer 2 schema is not a major
369 impediment since facets within a query can simply be ignored. For
370 example, all things being equal, a service that would not support
371 category, for example, could return the same results whatever value
372 of the category facet the user may specify. Obviously, one would
373 expect that the ability to accurately match results to the query
374 context passed by the client to be a strong service differentiator,
375 hence a market force to drive providers to fully implement the
376 required schema.
378 This last observation leads to the third point. Like the authors of
379 [SLS], we do not think that it is possible to impose a single context
380 of uniqueness to all namespaces (we define uniqueness of a namespace
381 as the minimum set of facets required to uniquely identify a record
382 within the namespace). We too, believe that the proper notion of
383 uniqueness is tied to the problem space tackled by the namespace, and
384 hence, will vary from one provider to another.
386 At the same time, we do not believe that it is possible to define a
387 Klensin's layer 2 schema capable of providing all namespaces with
388 sufficient context to ensure uniqueness and disambiguation for
389 lookups.
391 Instead, we see a practical solution in the middle. We believe that
392 some namespaces will require narrower context of uniqueness than the
393 complete schema that they expose to an application, using the extra
394 facets to facilitate disambiguation by end-users through an
395 interactive process (e.g. a user typing "Joe" could be asked to
396 disambiguate between the unique Keyword "Joe's seafood" in the
397 restaurant category and the unique Keyword "Joe body repair shop" in
398 the "body shop" category).
400 If this is true, defining the aforementionned layer as the ceiling to
401 provide disambiguation for lookup is not very useful. Indeed, it is
402 easy to envision that whichever standard set of facets we eventually
403 agree upon for this layer, a new namespace will emerge with new
404 requirements for uniqueness and disambiguation to prove us wrong.
406 In that case, we propose that it might be more appropriate to
407 consider defining the sets of facets that all namespaces should
408 support in order to provide interoperability, while at the same time
409 enabling each namespace to advertise to the applications the exact
410 set of facets that it really needs for uniqueness. The definition of
411 facets should be consistent, but each application should be able to
412 dynamically choose which facets to use. As applications exist and
413 will emerge that have different needs than DNS envisioned, use of
414 facets should be determinable by each application, not by a protocol
415 designed to suit the needs of the existing DNS system.
417 To illustrate that last point, let us consider a music namespace that
418 supports all the layer 2 facets proposed by John Klensin and a new
419 one called "singer" (the common name in this namespace is the title
420 of the song). Let us assume now that in this database of songs, the
421 context provided by the song and the singer's name is enough to
422 pinpoint a unique record. It is easy to see that:
424 - It would not be sufficient for an application to only use the
425 standardized layer 2 facets to disambiguate between songs (the
426 "singer" property is missing).
428 - It would be bad to prompt the user for the entire context
429 (language, geography, and category) supported by the namespace for
430 accessing a specific song, considering that in this case, only 2
431 facets would suffice.
433 - It would not be efficient for the application to store the full
434 context of the record if the goal is to bookmark a song for future
435 reference.
437 This observation leads to separating the notion of schema for
438 interoperability (the Klensin's layer 2 schema) from the notion of
439 uniqueness. There seems to be an agreement in the technical community
440 that one of the main reasons for introducing a new layer above DNS is
441 the lack of support for context in DNS names. At the same time, there
442 is no clear consensus on what scope of uniqueness should be
443 standardized.
445 Our feeling is that agreeing on a fixed context for uniqueness would
446 be an error. Context will always vary across providers and
447 namespaces, and it is not, nor should it be, a requirement to ensure
448 interoperability.
450 However, if we agree to let service providers disagree on rules of
451 uniqueness, we believe it is still important for applications to be
452 able to discover these rules at the service level. In fact,
453 applications need to understand how much context needs to be captured
454 from the user in order to disambiguate a query (lookup), and how much
455 context needs to be saved to be able to reference the same unique
456 record (bookmark). Without such capability, applications would have
457 to default to using layer one identifiers for uniquely referencing a
458 record.
460 Hence, there is a need for formalizing the notion of context-based
461 identifiers. Context-based identifiers or unique keys (to use a
462 database terminology) would allow a namespace to publish its own
463 context of uniqueness (the sets of facets that it uses for uniquely
464 identifying a record). Service providers would advertise one or many
465 of these unique keys.
467 Unique keys could subsequently be recognized and used by applications
468 to uniquely reference a record. We anticipate that applications will
469 take advantage of unique keys to minimize the user interface and the
470 interaction with the user for disambiguation during the lookup
471 process. As explained above, in a keyword system, such interaction is
472 kept to a minimum. The user simply types the common name (keyword)
473 although the application transparently passes the required context
474 (user country, language and the target service) for disambiguation.
475 If the name is unambiguous, the user accesses the resource directly;
476 otherwise a list of records is returned and presented to the user for
477 an interactive disambiguation.
479 5. Unique Keys
481 To formalize the notion of a context-based identifier or unique key
482 and enable each namespace to publish its rules of uniqueness, we
483 propose to introduce to CNRP a new mechanism to declare which facets
484 are part of the unique key. This mechanism will be used to express
485 the set of facets necessary to uniquely identify a single record for
486 a given service (possibly within each different service type). In
487 CNRP, a reference to facets is expressed using the
488 "propertyreference" property. This makes it relatively
489 straightforward for a service to describe its unique keys.
491 To illustrate this last point, let us consider a namespace of people
492 uniquely identified by their telephone number very much like the type
493 of service provided by ENUM [RFC2916]. Such service could advertise
494 its unique identifier comprised of the telephone number and the SLS
495 service target as follows (the common name is the telephone number):
497
498
500
501
502
503 urn:foo:bar
504
505
506 http://enum.example.com:4321
507
508
509 This is the definition of an ENUM like
510 SLS service
511
512 sls
513
514
515
516 commonname
517 E.164
518
519
520 service
521 sls
522
523
524 userpublicprofile
525 freeform
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
548 To put things in prospective, a typical query-response interaction
549 between an application and the service would look like this (in this
550 example, the application is looking for the user's email address):
552 C:
553 C:
555 C:
556 C:
557 C: +330493656172
558 C: email
559 C:
560 C:
562 S:
563 S:
565 S:
566 S:
567 S:
568 S: http://enum.example.com
569 S:
570 S:
571 S: +330493656172
572 S: mailto://jd@compuserve.com
573 S: email
574 S: This is
575 S: the best email address for Jean Dupont, Pediatrician
576 S: in Nice, France
577 S:
578 S:
579 S:
581 6. Standardization of Keyword Systems as a Class of Namespaces
583 This section describes a keyword system as a specific class of
584 namespaces. Although we use CNRP and the SLS proposal to formalize
585 the definition of a keyword system as a service type, the main goal
586 is to identify the elements of a namespace that require
587 standardization in order to define an interoperable class (aside from
588 the requirements identified previously).
590 Initiated by the CNRP effort, the standardization of keyword system
591 is a goal that has been revived by the Multilingual Internet Name
592 Consortium due to the rapid emergence of competing yet non-
593 interoperable services in Asia, notably in Korea and China. We hope
594 that this approach can establish a path toward the standardization of
595 keyword systems that would proceed in conjunction with the definition
596 of the broader directory layer above DNS.
598 We feel that the standardization of keyword system must imply the
599 following:
601 1. The definition of a list of service targets relevant to all
602 keyword systems (e.g. web, email, mobile-web, etc...)
604 2. For each of these target services, the definition of the unique
605 key common to all keyword systems.
607 For example, the standard could stipulate that the unique key for
608 keyword systems for the "web" target service be the combination of a
609 common name, a language, and a country. On the other hand, for the
610 target service "email", it is highly conceivable that the standard
611 would be defined on a very different set of facets (for example,
612 "organization name" could be one of the required facets).
614 7. Formalization of KLS Using The SLS Notation
616 Using CNRP, a client application could discover that a CNRP service
617 is a keyword system by issuing the standard CNRP "servicequery":
619
620
622
623
624
626 The service would then return a service object expressing the
627 characteristics common to all keyword systems (also note the
628 suggested use of the cnrp-service-type property as defined in the SLS
629 proposal):
631
632
634
635
636
637 urn:foo:bar
638
639
640 http://keywords.ex.com:4321
641
642
643 This is the definition of a keyword system as
644 an SLS service
645
646 sls
647
648 keywords
649
650
651
652 commonname
653 freeform
654
655
656 language
657 RFC1766
658
659
660 geography
661 ISO3166-1
662
663
664 service
665 sls
666
667
668
670
671
672
673
675
676
677
679
680
681
682
683
684
685
686
687 web
688
689
690
691
692
693
694
695
697 Note that the queryschema is only one path for an application to
698 discover that a CNRP service is a keyword system. Since the service
699 object is also embedded within the response to any query, the
700 application can simply recognize a keyword system by parsing the
701 information contained in the service object before processing the
702 query results.
704 8. Conclusion
706 As the network transforms, meta-data that provides context is
707 critical, and a flexible set of standards regarding collection and
708 use of meta-data must be defined. This will allow a wide
709 proliferation of namespaces to quickly develop that meet the needs of
710 the diverse worldwide population that uses the Internet.
712 9. References
714 [CNRP] N. Popp, M. Mealling, and M. Moseley, Common Name Resolution
715 Protocol (CNRP), draft-ietf-cnrp-10.txt, June 2001.
717 [DNSROLE] J. Klensin, Role of the Domain Name System, draft-klensin-
718 dns-role-01.txt, May 2001.
720 [DNSSEARCH] J. Klensin, A Search-based access model for the DNS,
721 draft-klensin-dns-search-01.txt, July 2001.
723 [RFC2916] P. Faltstrom, E.164 number and DNS, RFC 2916, September
724 2000.
726 [SLS] M. Mealling and L. Daigle, Service Lookup System (SLS), draft-
727 mealling-sls-00.txt, July 2001.
729 Author's Address
731 Yves Arrouye
732 RealNames Corporation
733 150 Shoreline Drive
734 Redwood City, CA 94065
736 Phone: (650) 486-5503
738 E-mail: yves@realnames.com
740 Keyword: RealNames
741 Web: http://www.realnames.com/
743 Vishesh Parikh
744 RealNames Corporation
745 150 Shoreline Drive
746 Redwood City, CA 94065
748 Phone: (650) 486-5507
750 E-mail: vparikh@realnames.com
752 Keyword: RealNames
753 Web: http://www.realnames.com/
755 Nico Popp
756 RealNames Corporation
757 150 Shoreline Drive
758 Redwood City, CA 94065
760 Phone: (650) 486-5549
762 E-mail: nico@realnames.com
764 Keyword: RealNames
765 Web: http://www.realnames.com/
767 Full Copyright Statement
769 Copyright (C) The Internet Society (2001). All Rights Reserved.
771 This document and translations of it may be copied and furnished to
772 others, and derivative works that comment on or otherwise explain it
773 or assist in its implementation may be prepared, copied, published
774 and distributed, in whole or in part, without restriction of any
775 kind, provided that the above copyright notice and this paragraph are
776 included on all such copies and derivative works. However, this
777 document itself may not be modified in any way, such as by removing
778 the copyright notice or references to the Internet Society or other
779 Internet organizations, except as needed for the purpose of
780 developing Internet standards in which case the procedures for
781 copyrights defined in the Internet Standards process must be
782 followed, or as required to translate it into languages other than
783 English.
785 The limited permissions granted above are perpetual and will not be
786 revoked by the Internet Society or its successors or assigns.
788 This document and the information contained herein is provided on an
789 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
790 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
791 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
792 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
793 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
795 Acknowledgement
797 Funding for the RFC Editor function is currently provided by the
798 Internet Society.