RFC 2972

Context and Goals for Common Name Resolution

📅 published October 2000, from ietf

RFC 2972: Context and Goals for Common Name Resolution 💖

okay bestie, this is RFC 2972, Context and Goals for Common Name Resolution, from the Network Working Group 🎀 It's Informational, so it's background and vibes, not a standard you have to follow. It's dated October 2000. The authors are N. Popp (RealNames Corporation), M. Mealling (Network Solutions), L. Masinter (AT&T Labs), and K. Sollins (MIT). The header doesn't list any RFCs it obsoletes or updates ✨

Status of this Memo 📜

this memo is just for info for the internet community, lowkey no internet standard here 🫶 distribution is totally unlimited, share away 🦋

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🌸

this doc sets up the context and goals for a Common Name Resolution Protocol 💅 it explains what a "Common Name" is, what it means to "resolve" one, and why plain "resolution" is different from fancier search stuff 🔍 it also covers some contexts where common name resolution would be used, and what makes a protocol count as successful 🏆 and it looks at why services might want to offer common name resolution for public, private, and commercial stuff, because the motivations are kinda iconic 👑

this doc is meant as input for forming a Common Name Resolution Protocol working group 🧚 send comments to cnrp-ietf@lists.internic.net and check the mail archives at <http://lists.internic.net/archives/cnrp-ietf.html> 💜

1. Introduction ✨

okay so people refer to real-world things by a common name or phrase all the time 💖 think trade names, company names, or book titles. these are way easier to remember and type than URLs, and lots of people find URLs hard to remember or type 😭 on top of that, because URL syntax is so limited, companies and individuals keep finding that the names that would make the most sense for their stuff are already taken somewhere else 💀 now, common names aren't URIs (Uniform Resource Identifiers), since they don't have the syntax structure URIs have 🙈 and unlike URNs, there's no requirement that a common name be unique or that its link to a resource stick around forever 🍓 these names are mostly for humans to use, not machines 🫶

common name "resolution" is the process of mapping common names to internet resources 🦋 and a Common Name Resolution Protocol (CNRP) is the network protocol used in that process ✨

a really useful comparison for understanding common names and CNRP is everyday dictionaries 📚 they cover a given language (a namespace), maybe a spoken language or some specific subset like technical terms 🤓 some dictionaries give definitions, others give translations to other languages 🌈 and different publishers can make dictionaries for the same language. like, Larousse and Collins can both publish French-language dictionaries 🇫🇷 so the dictionary publisher is basically the analog of the resolution service provider 💅 the service can add value and build up its own name recognition, but it doesn't stop other entities from providing definitions for the exact same strings in the language 🫶

services are popping up that map common names to internet resources (like things identified by a URI) 🔥 they usually handle categories like company names, trade names, or common keywords 🏷️ so a resolution service might work in one category or a small number of them, or it might expect the client to limit the resolution scope to a few categories or domains 🎯 for example, "Internet Engineering Task Force" is a common name in the "organization" category, and "Moby Dick" is one in the book category 📖 a single common name can be tied to different data records, and more than one resolution service is expected to exist 💫 any common name can be used in any resolution service 🌸

there are two classes of clients for these services being built right now 💻 first, browser improvements, where the "open" or "address" field of a browser is modified so you can type a common name instead of a URL ✨ second, web-accessible front-end services 🌐 internet search sites are adding common name resolution as a complement to regular search 🔍 in both cases, these can be clients of back-end resolution services 🧚 with browsers, the browser has to talk to a service that resolves the common name 🫶 search sites get accessed through a browser, and sometimes the search site is also the back-end resolution service 🙌 but other times the search site is just a front-end to a bunch of back-end services 👑

this effort is about making a protocol so client apps can talk to common name resolution services, as seen in both the browser enhancement and search site setups 💖 the protocol's main job is resolution, but it's also meant to handle internationalization, authentication, and privacy 🔐 name resolution services aren't generic search services, so they don't need complex Boolean queries, relevance ranking, or anything similar 🙅‍♀️ the protocol should be a simple, minimal, interoperable core 🎀 and mechanisms for extension will be provided, so more capabilities can be added later 🦋

a few other things matter for deploying common name resolution services, but they're outside the resolution protocol itself and not in this effort's initial scope 🚫 these include discovering and selecting resolution service providers, administering resolution services, name registration, name ownership, and methods for creating, identifying, or ensuring unique common names 💅

2. Key Goals for a Common Name Resolution Protocol 🎯

the key deliverable is a protocol for parameterized resolution 💜 "resolution" means retrieving data that's associated (a priori) with descriptors matching the input request 📦 "parameterized" means that a multi-component descriptor can show up both in the query and in the response 🧩 these descriptors are attribute-value pairs ✨ they aren't required to provide unique identification, so 0 or more records may be returned for any given input query 🤷‍♀️ the protocol will define:

  • client requests and server responses that identify the specific parameters accepted and/or required on input requests
  • client requests and server responses that identify properties to be returned in the result set
  • expression of parameterized input query
  • expression of result sets
  • standard expression of error conditions

to avoid building a general search protocol with unbounded complexity, and to keep things simple enough that different implementations behave similarly 🫶 the resolution protocol should be limited to sub-string matches against parameter values 🍬 for full internationalization, UTF-8 encoding of strings and sub-strings is preferred 🌏

also, the working group should define one sample service based on this protocol 🧁 that's the resolution of so-called "common names," meaning resolution of non-unique, registered strings to resource descriptions 🎀

3. CNRP goals 💅

the goal of CNRP is to create a lightweight search protocol with a simple query interface 🪶 the big focus is making the common case, substring search with a single result, super efficient 🔥 efficient support for keyed value search is important too 🗝️ each key is a named meta property of the resource, like category, language, or geographical region 🌍 some of these properties could be standardized, like the common name property 📛 the goal is to support partial specification of query parameters, and even partial and fuzzy matches on names 🦋 CNRP is meant to be simpler than LDAP for simple applications 💖

besides simplicity, the CNRP protocol should be consistent with efficient implementation of a simple, intuitive user interface ✨ the common name is the common denominator for finding a wide range of resources, so the UI gets reduced to its most minimal form: you type a few words in a text box and hit enter 🙌

CNRP should provide interoperability with multiple common name databases (section 4 has lots of examples of these databases) 🗂️ the query interface should be extensible and customizable to the specific needs of a particular type of resolution service 🧩 however, the need for interoperability across databases and resolution services, combined with the need to keep search scalable across millions of names from multiple providers, has led this group to consider an explicit requirement of supporting categories in CNRP 👑 this requirement is discussed further in section 5 🔜

4. Example of common name namespaces ✨

Okay bestie, let's look at who's already doing this! 💅 Commercial companies have already built and deployed common name resolution services like RealNames (http://www.realnames.com) and NetWords (http://www.netword.com). These are mainly about trade names like company names, brands and trademarks. They're a real-life example of common name namespaces, so they're super useful for seeing how big the CNRP effort is. 🦋

CNRP is also aimed right at directory service providers 🎀. It's relevant to them because it can help them reach more people by plugging into bigger sites like search portals. For example, IAtlas has built a directory service for businesses that it distributes through its website and Inktomi. IAtlas could instantly use CNRP to get its service out through its external distribution partners. 🌸

Directory services must not be confused with search engines 🙈. Directory services use highly structured information to identify a resource. That information lives outside the actual resource and is called metadata. Search engines, on the other hand, mostly rely on the content of the resource (like the text of a Web page).

CNRP vibes with directory services that present a critical piece of information about the resource as a textual identifier, a title or a terse description (the common name). There are so many examples: company names, book titles, people names, songs, ISBNs, and social security numbers. In every case, the common name is the natural thing users look things up by. The common name is always simple and intuitive: it has no syntax, it is multilingual, memorable and can often be guessed. 🧚

This list gives you a sense of just how wide the range of CNRP applications is 🌈:

  • Business directories (SEC, NASDAQ, E*Trade, .). The resource is company information (address, products, SEC filings, stock quotes, etc.). The common name is the company name.
  • White pages (BigFoot, WhoWhere, Switchboard, ...): The resource is a person (current address, telephone numbers, email addresses, employer, ...). The common name is a last name, a telephone number or an email address.
  • E-commerce directories: The resource is a product for sale (car, house, furniture, actually almost any type of consumption item). The common name is a brand name or a description.
  • Publishing directories: The resource is one of many things: a book, a poem, a CD, an MP3 download. The common name is an ISBN, a song title, an artist's name. The common name is typically the title of a publication.
  • Entertainment directories: The resource is an event (a movie, a concert, a TV show). The common name is the name or a description for the event, the movie title, a rock band name, a show.
  • Yellow pages services: Here again, the resource can be very diverse: a house for sale, a restaurant, a car dealership or other type of establishment or service that can be found in the traditional yellow pages. The common name can be a street address, the name of a business, or a description.
  • News feeds: The resource is a press article. The common name is the headline. 📰
  • Vertical directories: the DNS TLD categories, the ISO country codes. 🌍

5. Private and public namespaces 🔐

A set of common names within a category (books, news, businesses, etc.) is called a common name "namespace". The term "namespace" only refers to the set of names. It does not cover the bindings or associations between a name and data about the name (such as a resource, identified by a URI). Those bindings might be created and maintained by common name resolution services. Resolution services may create bindings that are relevant for the type of service they offer. 💭

It's useful to tell "private" and "public" namespaces apart 👀. A namespace is private if it's owned by an authority that controls the right to assign the names. A namespace is still private even if the right to assign those names is held by a neutral party.

A namespace is public when it isn't controlled by any single authority or resolution provider. Assignment of the names is distributed. Still, it's reasonable to expect that people who assign names will tend to pick names that have a minimum of collisions. For some of these namespaces, there will even be mechanisms to discourage duplicate assignment, but all of them are inherently ambiguous. Public namespaces are not controlled. Examples of public namespaces are:

  • Titles of books, movies, songs, poems, short stories, plays, or compilations
  • Place names
  • Street names
  • People's names

Because these namespaces are unbounded and open to any type of name assignment, they're going to have scalability problems 😭. To support these namespaces, CNRP must provide at least one standard mechanism to filter a large list of related results. A filtering mechanism must let the user narrow the search down to a smaller result set, because the common name alone may not be enough. 🎯

One possible search filter is tied to the idea of categories 🗂️. Categories create a structure to organize named resources, so large resolution services are likely to support some sort of categorization system (whether flat or hierarchical). Categories are an efficient search filter, but defining standard vocabularies for common name categories is beyond the scope of the protocol design. The protocol design for CNRP should not require a standardized taxonomy for categories in order to be effective. For example, CNRP resolution could use free-form keywords, and the end-user would use these keywords as part of the query. Each service would then be responsible for mapping the keywords to zero, one or many categories in its own classification. The keywords would stay classification independent, and different services could use different categorization schemes without compromising interoperability. It would then be up to the service to provide its own mapping. For example, let's say one namespace resolves names under the category "Hobby & Interests > collecting > antique > books". Assume that a second namespace has decided to organize the names of similar resources under the classification "Arts > Humanities > Literature > History of Books and Printing > antiques". Even though the two taxonomies are different, a CNRP query specifying category_keywords = "antique books" would let each service identify the appropriate category. This mechanism may ensure that the two result lists are small and coherent enough to be merged into one unique result set. It's important to note that this approach would work whether the classification is hierarchical or not. 🧠

Although this suggestion has merit, it's fair to say it remains unproven. In particular, it's unclear that the category_keywords property would guarantee full interoperability across resolution services. In any case, free-form keywords for specifying categories are just one of several possible ways of limiting the scope of a query. Although the specific mechanisms are not agreed upon at this time, CNRP will provide at least one standard mechanism for limiting scope. 🤞

6. Distributors/integrators of common name resolution services 🛍️

We anticipate two main categories of distributors for common namespaces. The first category is made up of Web portals such as search engines (Yahoo, MSN, Lycos, Infoseek, AltaVista, ...). A common name resolution service will typically address only one very specialized aspect of search (company names or book titles or people names, ..). This kind of focused lookup service is a useful complement to generic search. So portals are likely to integrate several types of common name services. CNRP solves the tricky problem of integrating multiple external, independent services within one Web site. Right now, the lack of standardization in performance requirements and query interfaces leads to loose integration (co-branded pages hosted on virtual domains) or maintenance problems (periodical data dumps). CNRP is aimed at solving some of these issues. CNRP makes it easier to deploy embedded services by creating a common interface to all common name services. 💖

The second category of distributors is made up of Web browser companies 🌐. Netscape's smart browsing (http://home.netscape.com/communicator/v4.5/index.html#smart) and Microsoft's IE5 auto-search features (http://www.microsoft.com/windows/Ie/Features/AutoSearch/default.asp) show that the two dominant Web browser companies understand the value of navigation and search from the command line of the browser. It's very clear how this command line could be used as the main user interface to common name resolution services through CNRP. In many ways, it's actually the most natural user interface for resolving a common name. For this strategic part of the browser's user interface to stay truly open to all common name resolution services, it's key that a standard resolution protocol (and a service discovery mechanism) exists. CNRP will give users access to the largest selection of services and providers, plus the ability to pick a specific resolution service over another. To protect users from proprietary implementations, the existence of CNRP is a prerequisite. 👑

7. Example of cost recovery models for maintenance of namespaces 💅

okay bestie, so this part is all about how people could actually make money off common name namespaces 💸 the whole point is to prove these things are commercially viable, which means CNRP is totally gonna show up in the market place 🛍️✨ there are 5 different cost recovery models, and they are lowkey iconic 👑

a. Licensing the lookup service 🎀

so in this model, the database owner licenses the data and the resolution service to a portal 🌸 this is a proven model, no cap. like, Looksmart (a directory service) recently licensed all their data to MSN 💻 another option is to sell access to the service straight to the user 💅 for some vertical type of common names service (e.g. patent search), it's also conceivable that a specific type of users (e.g., lawyers) would be willing to pay for accessing a precise resolution service ⚖️ it's giving very niche and very profitable 🤑

b. Sharing revenue generated by banner advertising 🦋

here the database owner licenses their infrastructure (data and resolution service) to a portal 💖 prepaid banner ads get placed on the result pages 🖼️ and the revenue gets split between the resolution service provider and the portal that hosts the pages 🫶 money money money 💸

c. Selling the names (charge the customer a fee for subscribing a name) 💎

this is a proven business model as well 🔥 (NSI, GOTO, RealNames, Netword, for of the name has a large user reach (search engines sell keywords for instance)). the original text here is a bit garbled 🙈 it reads "Netword, for of the name," so I'm keeping it exactly as written and not guessing what it meant 🧚

d. Value added service 🌈

another model is to build a common name as a free added value service so a core service feels more compelling to users ✨ for example, Amazon.com could create a common name namespace of book titles and make it freely available to its users 📚 Amazon.com wouldn't make any money from the resolution service per se 😌 however, it would indirectly, since the service helps users find (and therefore buy) more books from Amazon.com 🛒 big brain move 🧠💜

e. "Some-strings-attached" free names 🧵

a namespace may give users a name for free in exchange for something else 🎁 (like capturing the user's profile that can be sold to merchants, or capturing the user's email address to send advertising emails, etc.) 📧 free is never really free, periodt 💀

8. Security and Intellectual Property Rights Considerations 🔐

okay this section is serious, so pay attention 🫶 this document describes the goals of a system for multi-valued Internet identifiers ✨ it does not discuss resolution, so questions of secure or authenticated resolution mechanisms are out of scope 🚫 it also does not address means of validating the integrity or authenticating the source or provenance of Common Names 🙅‍♀️ issues about intellectual property rights tied to objects identified by the various Common Names are beyond the scope of this document too 💼 and so are questions about rights to the databases that might be used to construct resolvers 🗄️

9. Authors' Addresses 📮

Larry Masinter AT&T Labs 75 Willow Road Menlo Park, CA 94025

Phone: +1 650 463 7059 EMail: LMM@acm.org http://larry.masinter.net

Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon, VA 22070

Phone: (770) 935-5492 Fax: (703) 742-9552 EMail: michaelm@netsol.com

Nicolas Popp RealNames Corporation 2 Circle Star Way San Carlos, CA 94070-1350

Phone: 1-650-298-5549 EMail: nico@realnames.com

Karen Sollins MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139

Phone: +1 617 253 6006 EMail: sollins@lcs.mit.edu

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 🌍

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ♾️

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙏

Acknowledgement 🫧

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from