idnits 2.17.1 draft-ietf-cnrp-goals-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 477 lines 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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) == Unused Reference: 'CNRP-PROT1' is defined on line 412, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'CNRP-PROT1' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Nicolas Popp 2 April 28, 2000 Michael Mealling 3 Expires in 6 months Larry Masinter 4 draft-ietf-cnrp-goals-01.txt Karen Sollins 6 Context and Goals for Common Name Resolution 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document establishes the context and goals for a Common Name 33 Resolution Protocol. It defines the terminology used concerning a 34 "Common Name" and how one might be "resolved", and establishes the 35 distinction between "resolution" and more elaborate search 36 mechanisms. It establishes some expected contexts for use of Common 37 Name Resolution, and the criteria for evaluating a successful 38 protocol. It also analyzes the various motivations that would cause 39 services to provide Common Name resolution for both public, private 40 and commercial use. 42 This document is intended as input to the formation of a Common Name 43 Resolution Protocol working group. Please send any comments to 44 cnrp-ietf@lists.internic.net. To review the mail archives, see 45 47 1. Introduction 49 People often refer to things in the real world by a common name or 50 phrase, e.g., a trade name, company name, or a book title. These names 51 are sometimes easier for people to remember and enter than URLs; many 52 people consider URLs hard to remember or type. Furthermore, because of 53 the limited syntax of URLs, companies and individuals are finding that 54 the ones that might be most reasonable for their resources are already 55 being used elsewhere and therefore unavailable. Common names are not 56 URIs (Uniform Resource Identifiers), in that they lack the syntactic 57 structure imposed by URIs; furthermore, unlike URNs, there is no 58 requirement of uniqueness or persistence of the association between a 59 common name and a resource. These common names are expected to be used 60 primarily by humans (as opposed to machine agents). 62 A useful analogy for understanding the purpose and scope of common 63 names, and CNRP, are everyday (human language) dictionaries. These cover 64 a given language (namespace) -- perhaps a spoken language, or some 65 specific subset (e.g., technical terms, etc). Some dictionaries give 66 definitions, others give translations (e.g., to other languages). 67 Different entities publish dictionaries that cover the same language -- 68 e.g., Larousse and Collins can both publish French-language 69 dictionaries. Thus, the dictionary publisher is the analog to the 70 resolution service provider -- the service can provide a value-add and 71 build up name recognition for itself, but does not impede other entities 72 from providing definitions for precisely the same strings in the 73 language. 75 Services are arising that offer a mapping from common names to Internet 76 resources (e.g., as identified by a URI). These services often resolve 77 common name categories such as company names, trade names, or common 78 keywords. Thus, such a resolution service may operate in one or a small 79 number of categories or domains, or may expect the client to limit the 80 resolution scope to a limited number of categories or domains. For 81 example, the phrase "Internet Engineering Task Force" is a common name 82 in the "organization" category, as is "Moby Dick" in the book category. 83 A single common name may be associated with different data records, and 84 more than one resolution service is expected to exist. Any common name 85 may be used in any resolution service. 87 Two classes of clients of such services are being built, browser 88 improvements and web accessible front-end services. Browser enhancements 89 modify the "open" or "address" field of a browser so that a common name 90 can be entered instead of a URL. Internet search sites integrate common 91 name resolution services as a complement to search. In both cases, these 92 may be clients of back-end resolution services. In the browser case, the 93 browser must talk to a service that will resolve the common name. The 94 search sites are accessed via a browser. In some cases, the search site 95 may also be the back-end resolution service, but in others, the search 96 site is a front-end to a collection of back-end services. 98 This effort is about the creation of a protocol for client applications 99 to communicate with common name resolution services, as exemplified in 100 both the browser enhancement and search site paradigms. Although the 101 protocol's primary function is resolution, it is intended to address the 102 issues of internationalization, authentication and privacy as well. Name 103 resolution services are not generic search services and thus do not need 104 to provide complex Boolean query, relevance ranking or similar 105 capabilities. The protocol is expected to be a simple, minimal 106 interoperable core. Mechanisms for extension will be provided, so that 107 additional capabilities can be added later. 109 Several other issues, while of importance to the deployment of common 110 name resolution services, are outside of the resolution protocol itself 111 and are not in the initial scope of the proposed effort. These include 112 discovery and selection of resolution service providers, administration 113 of resolution services, name registration, name ownership, and methods 114 for creating, identifying or insuring unique common names. 116 2. Key Goals for a Common Name Resolution Protocol 118 The key deliverable is a protocol for parameterized resolution. 119 "Resolution" is defined as the retrieval of data associated (a priori) 120 with descriptors that match the input request. "Parameterized" means 121 the ability to have a multi-component descriptor both as part of the 122 query and the response. These descriptors are attribute-value 123 pairs. They are not required to provide unique identification, therefore 124 0 or more records may be returned to meet a specific input query. The 125 protocol will define: 127 . client requests/server responses to identify the specific parameters 128 accepted and/or required on input requests 130 . client request/server responses to identify properties to be returned 131 in the result set 133 . expression of parameterized input query 135 . expression of result sets 137 . standard expression of error conditions 139 To avoid creating a general search protocol with unbounded complexity, 140 and to keep the protocol simple enough so that different implementations 141 will have similar behavior, the resolution protocol should be limited to 142 sub-string matches against parameter values. To support full 143 internationalization, UTF-8 encoding of strings and sub-strings is 144 preferred. 146 In addition, the working group should define one sample service based 147 on this protocol -- the resolution of so-called "common names", or 148 resolution of non-unique, registered strings to resource descriptions. 150 3. CNRP goals 152 The goal of CNRP is to create a lightweight search protocol with a 153 simple query interface, with a focus on making the common case of 154 substring search with a single result most efficient. In addition, 155 efficient support for keyed value search is important. Each key is a 156 named meta property of the resource (e.g. category, language, 157 geographical region.). Some of these properties could be standardized 158 (e.g. the common name property). The goal is to support partial 159 specification of query parameters and even partial and fuzzy matches 160 on names. CNRP is intended to be simpler than LDAP for simple 161 applications. 163 Besides simplicity, the CNRP protocol should be consistent with 164 efficient implementation of a simple and intuitive user interface. The 165 emphasis on the common name as the common denominator to find a wide 166 range of resources reduces the UI to its minimal expression (the user 167 types a few words in a text box and presses enter). 169 CNRP should provide interoperability with multiple common name 170 databases (section 4 presents many examples of such databases). The 171 query interface should be extensible and customizable to the specific 172 needs of a specific type of resolution service. However, the need for 173 interoperability across databases and resolution services combined 174 with the need to ensure the scalability of search (across millions of 175 names from multiple providers) have lead this group to consider the 176 explicit requirement of supporting categories in CNRP. This 177 requirement is discussed further in section 5. 179 4. Example of common name namespaces 181 Commercial companies have already developed and deployed common name 182 resolution services such as RealNames (http://www.realnames.com) and 183 NetWords (http://www.netword.com). These commercial implementations are 184 mainly focused on trade names, such as company names, brands and 185 trademarks. These services constitute a concrete example of common name 186 namespaces implementation and are useful to understand the scope of the 187 CNRP effort. 189 CNRP is also directly targeted at directory service providers. CNRP is 190 relevant to these services to increase their reach through integration 191 into larger Web sites such as the search portals. For example, IAtlas 192 has developed a directory service for businesses that it distributes 193 through its Web site and Inktomi. IAtlas could immediately leverage CNRP 194 to distribute their service through their external distribution 195 partners. 197 Directory services must not be confused with search engines. Directory 198 services use highly structured information to identify a resource. This 199 information is external to the actual resource and is called metadata. 200 In contrast, search engines mainly rely on the content of the resource 201 (e.g. the text of a Web page). 203 CNRP plays well with directory services that present a critical piece of 204 information about the resource in the form of a textual identifier, a 205 title or a terse description (the common name). Numerous examples come 206 instantly to mind: company names, book titles, people names, songs, 207 ISBNs, and social security numbers. In all cases, the common name is the 208 natural property for users to lookup the resource. The common name is 209 always simple and intuitive: it has no syntax, it is multilingual, 210 memorable and can often be guessed. 212 The following list is intended to put in prospective the wide range of 213 applications for CNRP: 215 . Business directories (SEC, NASDAQ, E*Trade, .). The resource is 216 company information (address, products, SEC filings, stock quotes, 217 etc.). The common name is the company name. 219 . White pages (BigFoot, WhoWhere, Switchboard, ...): The resource a 220 person (current address, telephone numbers, email addresses, employer, 221 ...). The common name is a last name, a telephone number or an email 222 address. 224 . E-commerce directories: The resource is a product for sale (car, 225 house, furniture, actually almost any type of consumption item). The 226 common name is a brand name or a description. 228 . Publishing directories: The resource is one of many things: a book, 229 a poem, a CD, an MP3 download. The common name is an ISBN, a song 230 title, an artist's name. The common name is typically the title of a 231 publication. 233 . Entertainment directories: The resource is an event (a movie, a 234 concert, a TV show). The common name is the name or a description for 235 the event, the movie title, a rock band name, a show. 237 . Yellow pages services: Here again, the resource can be very diverse: 238 a house for sale, a restaurant, a car dealership or other type of 239 establishment or service that can be found in the traditional yellow 240 pages. The common name can be a street address, the name of a business, 241 or a description. 243 . News feeds: The resource is a press article. The common name is the 244 headline. 246 . Vertical directories: the DNS TLD categories, the ISO country codes. 248 5. Private and public namespaces 250 A set of common names within a category (books, news, businesses, etc.) 251 is called a common name "namespace". The term "namespace" only refers to 252 the set of names. It does not encompass the bindings or associations 253 between a name and data about the name (such as a resource, identified 254 by a URI). Such bindings might be created and maintained by a common 255 name resolution services. Resolution services may create binding that 256 are relevant for the type of service that they offer. 258 It is useful to distinguish between "private" and "public" namespaces. A 259 namespace is private if owned by an authority that controls the right to 260 assign the names. A namespace is private even if the right to assign 261 those names is held by a neutral party. 263 A namespace is public when not controlled by any single authority or 264 resolution provider. Assignment of the names is distributed. However, it 265 is reasonable to expect that people who assign names will tend to pick 266 names that have a minimum of collisions. For some of these namespaces, 267 there will even be mechanisms to discourage duplicate assignment, but 268 all of them are inherently ambiguous. Public namespaces are not 269 controlled. Examples of public namespaces are: 271 . Titles of books, movies, songs, poems, short stories, plays, or 272 compilations 273 . Place names 274 . Street names 275 . People's names 277 Because these namespaces are unbounded and open to any types of name 278 assignment, they will have scalability problems. To support these 279 namespaces, CNRP must provide at least one standard mechanism to filter 280 a large list of related results. A filtering mechanism must allow the 281 user to narrow the search further down to a smaller result set, because 282 the common name alone may not be enough. 284 One possible search filter is related to the notion of categories. 285 Because categories create a structure to organize named resources, large 286 resolution services are likely to support some sort of categorization 287 system (whether flat or hierarchical). Although categories constitute an 288 efficient search filter, defining standard vocabularies for common name 289 categories is beyond the scope of the protocol design. The protocol 290 design for CNRP should not require a standardized taxonomy for 291 categories in order to be effective. For example, CNRP resolution could 292 use free-form keywords; the end-user would use these keywords as part of 293 the query. Each service would then be responsible for mapping the 294 keywords to zero, one or many categories in their own 295 classification. The keywords would remain classification independent and 296 different services could use different categorization schemes without 297 compromising interoperability. It would then be up to the service to 298 provide its own mapping. For example, let us assume that one namespace 299 is resolving names under the category: "Hobby & Interests > collecting > 300 antique > books". Assume that a second namespace has decided to organize 301 the names of similar resources under the classification: "Arts > 302 Humanities > Literature > History of Books and Printing > 303 antiques". Although the two taxonomies are different, a CNRP query 304 specifying category_keywords = "antique books" would allow each service 305 to identify the appropriate category. This mechanism may ensure that the 306 two result lists are small and coherent enough to be merged into one 307 unique result set. It is important to note that this approach would work 308 whether the classification is hierarchical or not. 310 Although this suggestion has merit, it is fair to say that it remains 311 unproven. In particular, it is unclear that the category_keywords 312 property would guarantee full interoperability across resolution 313 services. In any case, free form keywords for specifying categories is 314 just one of several possible ways of limiting the scope of a query. 315 Although the specific mechanisms are not agreed upon a this time, CNRP 316 will provide at least one standard mechanism for limiting scope. 318 6. Distributors/integrators of common name resolution services 320 We anticipate two main categories of distributors for common namespaces. 321 The first category is made of the Web portals such as search engines 322 (Yahoo, MSN, Lycos, Infoseek, AltaVista, ...). A common name resolution 323 service will typically address only one very specialized aspect of 324 search (company names or book titles or people names, ..). This type of 325 focused lookup service is a useful complement to generic search. Hence, 326 portals are likely to integrate several types of common name services. 327 CNRP solves the difficult problem of integrating multiple external 328 independent services within one Web site. Today, the lack of 329 standardization in performance requirements and query interface leads to 330 loose integration (co-branded pages hosted on virtual domains) or 331 maintenance problems (periodical data dumps). CNRP is aimed at solving 332 some of these issues. CNRP facilitates the deployment of embedded 333 services by creating a common interface to all common name services. 335 The second category of distributors is made of the Web browser 336 companies. Netscape's smart browsing 337 (http://home.netscape.com/communicator/v4.5/index.html#smart) and 338 Microsoft's IE5 auto-search features 339 (http://www.microsoft.com/windows/Ie/Features/AutoSearch/default.asp) 340 demonstrate that the two dominant Web browser companies understand the 341 value of navigation and search from the command line of the browser. It 342 is very clear how this command line could be used as the main user 343 interface to common name resolution services through CNRP. In many ways, 344 it is actually the most natural user interface to resolve a common name. 345 For this strategic component of the browser's user interface to remain 346 truly open to all common name resolution services, it is key that there 347 exists a standard resolution protocol (and a service discovery 348 mechanism). CNRP will give users access to the largest selection of 349 services and providers and the ability to select a specific resolution 350 service over another. To preserve the user from proprietary 351 implementations, the existence of CNRP is a prerequisite. 353 7. Example of cost recovery models for maintenance of namespaces 355 The following discussion of possible business models for common name 356 namespaces is intended to prove that they are commercially viable, hence 357 that CNRP will be used in the market place. This section presents 5 358 different cost recovery models. 360 a. Licensing the lookup service 362 In such model, the owner of the database owner licenses the data and the 363 resolution service to a portal. This is a proven model. For example, 364 Looksmart (a directory service) recently licensed all their data to MSN. 365 Another possibility is to sell access to the service directly to the 366 user. For some vertical type of common names service (e.g. patent 367 search), it is also conceivable that a specific type of users (e.g., 368 lawyers) would be willing to pay for accessing a precise resolution 369 service. 371 b. Sharing revenue generated by banner advertising 372 In this model, the database owner licenses his infrastructure (data and 373 resolution service) to a portal. Prepaid banner ads are placed on the 374 result pages. The revenue is shared between the resolution service 375 provider and the portal that hosts the pages. 377 c. Selling the names (charge the customer a fee for subscribing a name) 378 This is a proven business model as well (NSI, GOTO, RealNames, Netword, 379 ...). It does not require a monopoly, it only requires that the vendor 380 for of the name has a large user reach (search engines sell keywords for 381 instance). 383 d. Value added service 384 Another model is to build a common name as a free added value service in 385 order to make a core service more compelling to users. For example, 386 Amazon.com could create a common name namespace of book titles and make 387 it freely available to its users. Amazon.com would not make any money 388 from the resolution service per se. However, it would indirectly since 389 the service would help the users find hence buy more books from 390 Amazon.com. 392 e. "Some-strings-attached" free names 393 A namespace may give users a name for free in exchange for something 394 else (capturing the user's profile that can be sold to merchants, 395 capturing the user's email address in order to send advertising emails, 396 etc.). 398 8. Security and intellectual property rights considerations 400 This document describes the goals of a system for multi-valued 401 Internet identifiers. This document does not discuss resolution; 402 thus questions of secure or authenticated resolution mechanisms are 403 out of scope. It does not address means of validating the integrity 404 or authenticating the source or provenance of Common Names. 405 Issues regarding intellectual property rights associated with objects 406 identified by the various Common Names are also beyond 407 the scope of this document, as are questions about rights to the 408 databases that might be used to construct resolvers. 410 9. References 412 [CNRP-PROT1] draft-popp-cnrp-00.txt, "A resolution protocol for Common 413 Name Namespaces", Nicolas Popp and Michael Mealling, February 1999. 415 10. Authors Addresses 417 Larry Masinter 418 AT&T Labs 419 75 Willow Road 420 Menlo Park, CA 94025 421 tel: +1 650 463 7059 422 fax: +1 650 463 7073 423 email: masinter@attlabs.att.com 425 Michael Mealling 426 Network Solutions 427 505 Huntmar Park Drive 428 Herndon, VA 22070 429 voice: (770) 935-5492 430 fax: (703) 742-9552 431 email: michaelm@netsol.com 433 Nicolas Popp 434 RealNames Corporation 435 2 Circle Star Way 436 San Carlos, CA 94070-1350 437 Phone: 1-650-298-5549 438 Email: nico@realnames.com 440 Karen Sollins 441 MIT Laboratory for Computer Science 442 545 Technology Sq. 443 Cambridge, MA 02139 444 Phone: +1 617 253 6006 445 EMail: sollins@lcs.mit.edu 447 11. Full Copyright Statement 449 Copyright (C) The Internet Society (1999). All Rights Reserved. 451 This document and translations of it may be copied and furnished to 452 others, and derivative works that comment on or otherwise explain it 453 or assist in its implementation may be prepared, copied, published 454 and distributed, in whole or in part, without restriction of any 455 kind, provided that the above copyright notice and this paragraph are 456 included on all such copies and derivative works. However, this 457 document itself may not be modified in any way, such as by removing 458 the copyright notice or references to the Internet Society or other 459 Internet organizations, except as needed for the purpose of 460 developing Internet standards in which case the procedures for 461 copyrights defined in the Internet Standards process must be 462 followed, or as required to translate it into languages other than 463 English. 465 The limited permissions granted above are perpetual and will not be 466 revoked by the Internet Society or its successors or assigns. 468 This document and the information contained herein is provided on an 469 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 470 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 471 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 472 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 473 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.