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.