INTERNET-DRAFT Marshall L.Moseley February 19, 1999 MPC Technology Expires August 19, 1999 Shep Bostin draft-moseley-ohfn-00.txt Netword, Inc. An Architecture for Open Human Friendly Naming of Internet Resource Addresses ("URLs") 1. Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract As use of the Internet has become widespread, it's become increasingly clear that the URL -- the mechanism most users employ to designate resources -- is inherently confusing to non-technical users, and to a great extent, is unusable by them. For that reason, an easier naming scheme that employs human-friendly names ("HFNs") is desirable and necessary. Such schemes have been discussed at length in RFCs 1737[1], 2276[2] and 2168[3]. This document describes a set of requirements for potential HFN schemes. These requirements are RFC-compliant, open, and encompass available HFN proposals. For purposes of this document, those requirements are referred to as "OHFN" (open human- friendly naming). An OHFN-compliant scheme will allow users to enter plain-language words or phrases into their web browsers, and have those identifiers resolve to valid Internet resources. 3. Introduction The Internet is unfriendly to users with little technical experience. Most Internet resources are available only to those who know the exact location description of what they're looking for. For example, URLs specify an Internet location, while an FTP site employs the hierarchical directory structure common to UNIX, VMS, FAT, FAT-32, and MacOS systems. Move an Internet resource from its previously known location, and users get the broken links and "404 Errors" that are ubiquitous nowadays. RFC 1737 partially overcomes this problem by specifying the functional requirements for a location-independent identifier called a Uniform Resource Name ("URN")[1]. URNs, however, are designed to make identifier resolution easier for computers rather than human beings[2]. From RFC 2276: "Furthermore, the group decided that [URNs] were generally to be for machine, rather than human, consumption." Clearly, some type of facility will have to be employed to make the experience of navigating and using the Internet less challenging, especially to non-technical users. RFC 2276 goes on to describe such a facility[2]: "In contrast to URNs, one can imagine a variety of human-friendly naming (HFN) schemes supporting different suites of applications and user communities. These will need to provide mappings to URNs in tighter or looser couplings, depending on the namespace. It is these HFNs that will be mnemonic, content-full, and perhaps mutable, to track changes in use and semantics. They may provide nicknaming and other aliasing, relative or short names, context sensitive names, descriptive names, etc." The above quote is a very loose definition, but it nevertheless indicates a direction to follow when specifying the requirements of an HFN scheme. Another indication comes from the Uniform Resource Identifiers working group ("URI- WG"). The URI-WG combined and revised several URN proposals into a single compromise specification called the Knoxville Framework. RFC 2168 states[3]: "The major principle behind the Knoxville framework is that the resolution system must be separate from the way names are assigned." This proposal indicates that any URN specification will be open, with resolver services functioning as independent entities and the URNs adhering to non-proprietary standards. Clearly, any HFN scheme in which HFNs map to URNs must also be open. 4. Requirements for an OHFN The purpose of an OHFN is to provide a human-friendly facility by which users can specify and access Internet resources. Hence, an OHFN must serve two masters: it must (a) be technically sophisticated, providing seamless and robust mapping to URNs; and (b) remain usable, understandable, and logical to the average user. 4.1. Language and text An OHFN must be multi-lingual; it must be able to parse and act upon standard language words and phrases, including spaces and special characters. Those characters should be hex-escaped UTF-8 encoded Unicode strings as described in RFC 2141[4]. 4.2. URN compatibility An OHFN must conform to the Knoxville Framework for URN specifications, as outlined in the URN Progress Report of 2/96[5]. The following is an example from the said report of the proposed URN syntax: urn:hdl:cnri.dlib/august95 urn:lifn:some.domain:anything-goes-here urn:path:/A/B/C/doc.html urn:inet:library.bigstate.edu:aj17-mcc By including a naming scheme identifier, URNs explicitly indicate the naming scheme employed--"hdl", "lifn", "path", "inet", etc. The above begs the question of how a name is to be resolved, because it is impossible for all resolvers to work with all naming schemes. RFC 2168[3] addresses that by suggesting the creation of resolver discovery services ("RDSs") that employ the current DNS system and include a "NAPTR" (Naming Authority PoinTeR)[3]. An RDS, upon parsing a URN and determining the specified naming scheme, would use NAPTR to pass the URN to the resolver associated with the naming scheme. Hence URN/resolver independence is achieved by each resolver employing a URN registry[5] that also functions as an OHFN registry. 4.3. Client software Most of the discussion of HFNs has centered on how Internet-based services will handle them. However, it's also important to discuss what happens 'under the hood' on the client side. Note that while what follows applies to Web browsers, it is independent of whether browser technology migrates into client operating systems. Therefore, when we discuss OHFN-compliance on the client side, we include the possibility that the client may be embedded in operating system services. 4.3.1. Usability An important subject to address is 'usability,' which, in this context, means the user experience when accessing a URL. That experience must be simple, and one in which the user understands the logic, correctness and ease of the HFN facility. Specifically, an HFN cannot demand that users do something to satisfy a technical requirement, but is unexplained and therefore appears to be arbitrary. For example, just a short time ago, users were required to key in the type of Internet transport they wanted to use in accessing a resource: HTTP, Gopher, etc. From a technical standpoint that makes eminent sense; from the user's perspective, they had to type gibberish before they could read a Web page, or a text file. 4.3.2. Precedence To allow users to enter plain-language phrases, the client-side software must apply rules of precedence in order to understand which HFN scheme is requested. In the current versions of Web browsers, ambiguity remains as to how to interpret plain-language phrases (though the requirement of specifying a transport is gone). Microsoft Internet Explorer 4.x, for example, handles plain language by passing any phrase it doesn't understand to a Web-based search engine. In the future, Web browsers should use default, primary HFNs to which they pass any string the user types in that is not a URL, or easily translatable to a URL. If the HFN resolver returns an error, a precedence of HFNs would move to the next naming scheme installed into a Web browser. The precedence of HFNs should be user-configurable. The process of employing multiple HFNs by precedence should be transparent to the user, so that an error message is returned only when all installed HFNs return errors. The HFNs precedence will end the need to key in special identifiers before typing in a plain-language phrase, and the use of software clients to work around Web browsers' inherent limitations. That precedence also solves the problem of duplicate names under different schemes -- lacking any namespace identifier, users will see the Internet resource specified by the default HFN. Finally, the precedence does not preclude the use of traditional transport identifiers, such as HTTP, to override HFNs when requesting Internet resources. 4.3.3. Identification and location Any HFN scheme should offer a facility whereby any Internet resource that is active -- that is, in a Web browser right now, or selected, or being indicated with a mouse -- can be associated with HFNs that are created at that moment. An HFN would contain all relevant identification and location information (domain, IP and port, etc.) and be mapped to a URN. Alternately, users should have an ability to create an HFN by running a program, or by accessing an online application system of some sort, and keying in resource locations or URNs. (Note: at this stage, 'identification information' can be as simple as a Web page's name and URL, or as complex as a URN associated with a rich namespace.) As URNs become more widespread and replace URLs as the default navigation system on the Web, it will be easier for client-side software to create HFNs that denote URNs, and their attendant resolution services. Therefore, the minimum standard for OHFN-compliance on the client side is that the client (1) parse plain-language phrases, (2) employ a logical precedence in passing HFN text strings to the appropriate resolver, or RDS, and (3) create HFNs that correctly encode any Internet resource's identification and location information. Beyond this, additional client-side features are value-added characteristics that will differentiate HFNs in the marketplace. 4.4. HFN availability The creation of HFNs breaks down into two different scenarios. In scenario one, a commercial entity, or large organization wants potential customers and users to be able to locate their online resources more easily. Thus, owners of online resources want to register an easily remembered name, perhaps identical to their company, product, brand or trademark. Owners would register their trademarks with the popular HFN suppliers, and that will ensure that users may reach their resources easily, regardless of the precedence rules used by their clients. Registration could take place instantly, online, or over a period of time (a few days or a week), and would be accomplished easily. That should be a satisfactory scenario for trademark holders, since their naming strategies are more deliberate, and typically less time-critical. The vast majority of HFNs will likely be created by individual users, on an "on demand" basis, to avoid typing complex URLs. In that second scenario, immediate availability of created HFNs becomes important. Thus, any OHFN-compliant scheme should allow for the creation and availability of HFNs in real-time to meet the expectations and demands of individual users, since they will probably represent the majority of HFN creators. Once a user or a resource owner creates an HFN, it should be instantly available to any OHFN-capable resolver on the planet. 4.5. Trademarks and HFNs As HFNs become more popular, there will invariably be disputes concerning a given HFN relative to the popularity of the Internet resource it denotes and the entities involved. That is especially true if HFNs are globally unique, a strategy that a number of HFN suppliers are likely to adopt. It is beyond the scope of this document to suggest registration priorities, or how or whether to arbitrate disputes. It is recommended that HFN naming authorities seek advice from counsel to create a set of registration priorities that respects the rights of trademark holders, and allows users to create HFNs easily and quickly. It is reasonable to suggest that an OHFN-compliant scheme that does not excessively restrict the registration of HFNs that match certain trademarks need not, by definition, create a system that cannot provide reasonable protection of those marks. 4.6. Internet resources An OHFN-compliant naming scheme should be flexible enough to name all forms of Internet resources. In addition to HTML and standard formats, an OHFN should be backwards-compatible with older Internet standards (gopher, wais, etc.), and able to handle most conceivable formats that are introduced. This includes text, graphics, video, voice, MP3, etc. That type of over-arching statement ("Handle everything!") is possible since an HFN is a pass-through mechanism that helps to connect a user to the Web content that they want to use. The assumption is that the software on the client, or server side will work with the data and/or programs requested. 4.7. Syntax The following is a suggested syntax for an OHFN-compliant HFN scheme. urn:: ::== [/][/ | /] ::== hex-escaped UTF-8 encoded Unicode string ::== hex-escaped UTF-8 encoded Unicode string ::== hex-escaped UTF-8 encoded Unicode string ::== hex-escaped UTF-8 encoded Unicode string Where is the HFN identifier, and contains the content of the HFN itself. In this case is an optional qualifier on an HFN that allows for scoping of HFNs to a particular sub-network or geographic area. This would allow for 'regional' or 'local' HFNs. For example, the HFN phrase 'plumbers' might return different information in different cities, depending upon specified, or default path information. A root HFN is a unique identifier that, in conjunction with branch HFNs, allows for the creation of rich namespaces by individual users, or organizations. For example, a user may not be able to reserve a global, generic term such as "sports" because it is already taken, but by creating a root HFN such as "UserX", a user can have UserX/Sports and go directly to a favorite sports Web page. Dynamic HFN parameter strings are reserved to individual HFN providers for their internal use, or to provide value-added services. They are specified here for complete mapping of OHFN-compliant HFNs to URNs. They also allow for the passing of additional parameters to HFN providers that are beyond the scope of this OHFN proposal. 4.8. HFN identifier syntax This identifier syntax is identical to that specified for URNs in RFC 2141[4]. It is designed to be consistent with all potential resolution schemes. ::= [ 1,31 ] ::= | | | "-" ::= | | ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" 5. Conclusions The requirements for OHFN-compliance set forth herein are intentionally open-ended and describe the general behavior of those mechanisms that process HFNs, rather than dictating an HFN structure down to a granular level. This leaves room for the definition of OHFN-compliance to be extended in the future, and allows for HFN vendors to differentiate themselves in the marketplace. 6. Author contact information Marshall L. Moseley MPC Technology 2675 Windsor Circle East Eugene, Oregon 97405 U.S.A. +1 541.343.6332 / fax 541.343. 6362 Shep Bostin Netword, Inc. 702 Russell Avenue, Third Floor Gaithersburg, Maryland 20877-2606 U.S.A. +1 240.631.1100 / fax +1 240.631.9583 Copyright (c)1999 Netword, Inc. All Rights Reserved. This document, and translations may be copied and furnished to others. Derivative works that comment on or otherwise explain this document, 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 listed copyright notice, and this paragraph are included on all such copies and derivative works. However, this document and translations may not be modified in any way, such as removing the copyright notice, or references to Netword, Inc., or other organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process are followed, or as required to translate it to languages other than English. The limited permissions granted in the preceding paragraph are perpetual and will not be revoked by Netword, Inc., its successors or assigns. This document and the information contained therein is provided on an "AS IS" basis and NETWORD, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION CONTAINED HEREIN WILL NOT INFRINGE UPON ANY RIGHTS, OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. [1] K. Sollins, L. Masinter; Request for Comments: 1737. Functional Requirements for Uniform Resource Names [2] K. Sollins; Request for Comments: 2276. Architectural Principles of Uniform Resource Name Resolution. [3] R. Daniel, ; M. Mealling; Request for Comments: 2168. Resolution of Uniform Resource Identifiers using the Domain Name System [4] Ryan Moats, Request for Comments: 2141. URN Syntax, May 1997. [5] The URN Implementers, Uniform Resource Names: A Progress Report, http://www.dlib.org/dlib/february96/02arms.html, D-Lib Magazine, February 1996. This INTERNET-DRAFT Expires August 19, 1999