idnits 2.17.1 draft-popp-realname-hfn-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: ---------------------------------------------------------------------------- ** 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 490 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 an Authors' Addresses Section. ** The abstract seems to contain references ([RFC2276]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) -- Missing reference section? '1' on line 420 looks like a reference -- Missing reference section? '2' on line 422 looks like a reference -- Missing reference section? '3' on line 425 looks like a reference -- Missing reference section? '4' on line 428 looks like a reference -- Missing reference section? '5' on line 431 looks like a reference -- Missing reference section? '6' on line 435 looks like a reference -- Missing reference section? '7' on line 438 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Nicolas Popp 3 draft-popp-realname-hfn-00.txt Centraal Corporation 4 September 23, 1998 Larry Masinter 5 expires in six months Xerox Corporation 7 The RealName System: a Human Friendly Naming scheme 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Abstract 30 The notion of a 'Human Friendly Naming scheme' (HFN) has been 31 discussed in a variety of contexts, as an alternative to the use of 32 URIs or URNs as a way of designating Internet resources (see [RFC 33 2276], for example). 35 This document introduces the RealName system, and its use as a 36 HFN. It provides a mapping for RealNames into a URN namespace ('rn') 37 as well as a URL scheme ('vnd.rn'). 39 This is a preliminary draft, intended to raise the discussion of 40 HFNs and the uses of RealNames as an initial example in creating a 41 standard for access and resolution. 43 1. Introduction 45 It has been widely recognized that the URL syntax and structure has 46 been unfriendly (frustrating and confusing) for non-technical 47 Internet users, and that the URN naming system retains the 48 'unfriendly' behavior. For example, from RFC 2276: 50 In contrast to URNs, one can imagine a variety human-friendly 51 naming (HFN) schemes supporting different suites of applications 52 and user communities. These will need to provide mappings to URNs 53 in tighter or looser couplings, depending on the namespace. It is 54 these HFNs that will be mnemonic, content-full, and perhaps 55 mutable, to track changes in use and semantics. They may provide 56 nicknaming and other aliasing, relative or short names, context 57 sensitive names, descriptive names, etc. Their definition is not 58 part of this effort, but will clearly play an important role in 59 the long run. 61 URLs provide a powerful mechanism to resolve the location of 62 resources on the Internet. For many applications, though, URLs are 63 complex, totally unpredictable, and too lengthy to memorize. 65 In order to facilitate the adoption of the Internet by the broad 66 non-technical audience, it is desirable to simplify Internet 67 navigation via a simpler, globally available, human friendly naming 68 system. 70 The RealName system has such user friendly naming as a goal. By 71 simplifying navigation on the Internet, it aims at facilitating the 72 adoption of the Internet by novice users. The RealName System 73 primarily focuses on World Wide Web pages that can be associated 74 with a trade name. Examples of trade names are brands 75 (e.g. "Tylenol"), company names (e.g. "Apple Computer Inc"), 76 trademarks (e.g. "Coca-Cola") and advertising slogans (e.g. Nike's 77 "Just do it"). The RealName system offers a familiar interface to 78 users: simple everyday words in their own language. Each year, 79 commercial entities invest vast amount of marketing dollars in order 80 to promote their brands and ensure that these names are known by 81 millions of consumers all around the planet. Brand names are catchy, 82 and mnemonic for commercial reasons and cross media advertising 83 provides powerful means to guarantee that these names are 84 universally known. For all these reasons, brand names are great 85 candidates as HFNs. 87 Another fundamental value of a RealName is that it is by nature a 88 name and not an address. Unlike most URLs, a RealName does not 89 contain any information about the location of the resource that it 90 refers to. Hence, a RealName is a more persistent name than the 91 traditional HTTP URL of a Web page. If a user has bookmarked an HTTP 92 URL and it changes, the resource can no longer be found. In the 93 RealName System, HTTP URLs can change without impacting 94 navigation. This level of indirection has clear benefits for 95 navigating on the Internet. It also requires a new piece of 96 infrastructure: a name resolution service. The RealName resolver is 97 a backend service that maps RealNames into URLs. 99 In addition to increased robustness, name resolution services can 100 provide benefits such as the ability to access metadata and discover 101 resources characteristics prior to accessing it. The RealName 102 resolution service provides simple query capabilities so that a user 103 can search the namespace and discover new RealNames. 105 The notions of location independence, persistence and name 106 resolution service are core to the concept of URN as presented in 107 RFC 2141 [1]. The RealName system also provides a URN namespace; 108 Section 3 of this document defines a compliant URN syntax for 109 RealNames and proposes the RealName System as a formal URN 110 namespace; Section 4 of this document defines a compliant URL syntax 111 for RealName locators using the (undated) form of the RealName URN. 113 Human Friendly Names can be considered a new class of URI that are 114 neither URNs nor URLs. The RealName system is proposed as an initial 115 example of HFNs, and as the basis for future standardization of the 116 general class. 118 2. The RealName system as a Human Friendly Name scheme 120 A "RealName" is a name registered with Centraal Corporation. 121 Centraal Corporation owns and manages the RealName repository 122 database and is the sole assigning authority for RealNames. Names 123 are arbitrary strings, encoded in Unicode UTF-8. The Centraal 124 realname resolution service offers a variety of different searching 125 and matching mechanisms for looking up and searching the database of 126 RealNames. The result of RealName resolution is a set of metadata 127 about the resource, including available URLs and URNs. 129 3. Mapping the RealName System into a formal URN namespace 131 The RealName system also forms the basis of a formal URN namespace. 132 The URN namespace consists only of the canonical registered 133 representation of a RealName. That is, while a RealName HFN might be 134 part of a database to be searched, the RealName URN is used for 135 canonical lookup. 137 A specification template is submitted according to the guidelines 138 defined in the IETF working draft on URN Namespace Definition 139 Mechanisms [2]. 141 2.1. The "rn" URN namespace Specification Template 143 Namespace ID: 144 "rn" requested. 146 Declared registrant of the namespace: 147 Nicolas Popp 148 nico@centraal.com 150 Relevant ancillary documentation: 151 An introduction to the RealName System can be found on the 152 Centraal Corporation Web site at http://company.realnames.com. 153 Also note that an implementation of the RealName resolution 154 service is available at http://www.realnames.com as well as from 155 http://altavista.digital.com. 157 Declaration of structure: 158 The identifier structure is as follows: 159 urn:rn: 161 The being defined as: 162 ::= "/" 163 ::= (hex-escaped opaque string) 164 ::= (hex-escaped UTF-8 encoded Unicode string) 166 Conceptually, the organizes the namespace in distinct sub 167 name spaces and gives the RealName URN a hierarchical 168 structure. The is automatically assigned by Centraal. 170 The component of the NSS is the document's RealName 171 expressed in the URN canonical form as specified in RFC 2141 172 [1]. A RealName is a globally unique name that has a natural 173 language structure. 175 Identifier uniqueness considerations: 176 The Centraal repository database enforces the uniqueness of URNs 177 for all subscribed RealNames as an integrity constraint. This 178 guarantees that a RealName URN is unique across the entire name 179 space. 181 Centraal Corporation owns and manages the RealName repository 182 database and is the sole assigning authority for RealNames. 184 Identifier persistence considerations: 185 A RealName will persist in the repository beyond the life of the 186 Web page that it points to. Nevertheless, since commercial 187 entities and their brands can be replaced, it is possible on 188 occasion that a RealName be reassigned. For example, this would be 189 the case if a corporation had ceased to exist and later, a new 190 company was incorporated under the exact same name. In such 191 instance, the new corporation could legitimately subscribe and be 192 reassigned the defunct company's RealName. 194 To ensure that a RealName URN always points to the same 195 resource, the for the RealName URN is changed 196 each time a RealName is reassigned. This guarantees that the 197 new RealName has a different URN than the old one. 199 In the first implementation of the RealName System, the URN 200 is the calendar year of the subscribed RealName (note 201 that the proposed syntax is more general to allow future 202 evolution). Since RealNames are subscribed on a yearly basis, and 203 Centraal guarantees that a RealName cannot be reassigned for at 204 least one year, the RealName URN is therefore persistent. 206 Process of identifier assignment: 207 Organizations and Web site owners can subscribe to a RealName 208 using an online subscription service. This service is available at 209 https://customer.realnames.com. Centraal Corporation usually 210 charges a yearly maintenance fee for each subscribed 211 RealName. Unlike domain names that are registered on a first-come 212 first-served basis, Centraal exercises management and adjudication 213 processes to ensure that a RealName is assigned to the 214 'appropriate' Web page. Centraal's terms and conditions require a 215 subscriber to choose a RealName that represents 'appropriate use' 216 for the specified Web page. If Centraal judges that a subscribed 217 RealName is not 'appropriate', it rejects it. To assess whether or 218 not the RealName that has been chosen by the subscriber is 219 'appropriate', Centraal has established a department of the 220 company to make this determination. 222 'Appropriate use' should be interpreted loosely as meaning: will 223 the Internet user community anticipate coming to the aliased Web 224 page when using the RealName for navigation. Accordingly, common 225 terms such as "books", "music" or "cars" are improper RealNames 226 and cannot be subscribed because they are not unique to a single 227 commercial Web page. 229 Centraal Corporation is therefore the sole assigning and managing 230 authority for the RealName System. However, in the future, it is 231 conceivable that the in the RealName URN could be used as 232 a mechanism to partition the name space and delegate some of the 233 administrative authority to a third party. 235 Process for identifier resolution: 236 Centraal operates a form-based Web resolution service at 237 http://www.realnames.com. The RealName resolvers are built on 238 indexing and clustering technology. Hence, they can handle large 239 numbers of resolutions and can be distributed across the 240 Internet. As of today, Centraal has deployed two clusters of 241 resolvers, one on the East Coast and one on the West Coast of the 242 United States. The current service resolves more than 5 millions 243 RealNames a week while only operating at 20% of its current 244 capacity. In the near future, some portions of the resolution 245 service will be delegated to Centraal's partners all around the 246 globe. 248 Centraal will follow new registration guidelines and implement the 249 mechanisms necessary to support emerging RDS standards. For 250 instance, Centraal will subscribe to URN.NET and will maintain a 251 list of active resolvers as NAPTR records in the DNS. 253 Centraal has already prototyped an experimental URN resolver 254 implementing the NAPTR Resolver Discovery Service as described in 255 RFC 2168 [3]. 257 Centraal will support THTTP and implement the N2L, N2N and N2C 258 resolution services as described in the Internet draft "URI 259 Resolution Services Necessary for URN Resolutions" [4]. 261 Rules for Lexical Equivalence: 262 RealNames are case insensitive. Characters with and without 263 diacritics such as accent and vowel marks are distinguished. 265 To give an example (using an ASCII representation of accented 266 characters), the RealName 'la de'pe^che du midi' is not equivalent 267 to the Realname 'la depeche du midi'. The internal representation 268 of a RealName is Unicode 2.1. 270 Hence, RealName URNs should be compared based on Unicode string 271 equivalence as described in [5]. In particular, encoding 272 artifacts invisible to the user should be accounted for when 273 assessing the equivalence of two RealNames. 275 Conformance with URN Syntax: 276 There are no reserved characters in the RealName System. The 277 reserved characters of the URN syntax will be escaped as specified 278 in RFC 2141 [1] to ensure full conformance with that syntax. In 279 particular, the component of the NSS is the 280 hex-encoding of the UTF-8 for that RealName. For example, the 281 RealName 'porsche boxster' becomes: 283 urn:rn:1998/porsche%20boxster 285 Validation mechanism: 286 The RealName online subscription service available at 287 https://customer.realnames.com provides a mechanism to check 288 whether a RealName is already in use. Subscribers can also 289 directly contact a name space management representative by email 290 or telephone in order to assess what RealName is appropriate for 291 their Web page. 293 Scope: 294 The RealName System introduced in this document does not aim to 295 provide a RealName for every Web page on the Internet. Rather, it 296 focuses on the subset of Web pages that can be unambiguously 297 associated with a commercial brand name, trademark or company 298 name. RealNames will be available in all human languages. 300 RealNames are globally unique and usable across the entire 301 Internet. Therefore, the scope of a RealName URN is global. 303 2.2. Examples 305 The following are examples of URNs that a RealName resolver can 306 resolve: 308 urn:rn:1998/bambi 309 urn:rn:1998/bmw%20z3 310 urn:rn:1998/tylenol 312 2.3. Security Considerations 314 The primary security risk in the use of identifiers is that in some 315 way the resource reached when following a reference will not 316 correspond to the resource intended. The RealName system maintains a 317 centralized scope of authority, but the reliability of the mapping 318 depends on the security of the RealName mapping system. 320 3. A Proposal for the RealName System as a URL scheme 322 This section of the document proposes the RealName System as a new 323 URL scheme in the vendor tree. A complete registration template is 324 presented according to the guidelines defined in [6]. 326 3.1 Registration Template: 328 URL Scheme Name: 329 "vnd.rn" requested. 331 Scope: 333 The RealName System focuses on the subset of Web pages that can be 334 unambiguously associated with a commercial brand name, trademark 335 or company name. RealNames may be in any human language. RealNames 336 are globally unique and usable across the entire Internet; thus, 337 the scope of a RealName URL is global. 339 Conformance with URL Syntax and Character encoding considerations: 341 A RealName URL reads 342 vnd.rn: 343 where 344 :: = (hex-escaped UTF-8 encoded UNICODE string) 346 There are no reserved characters in the RealName System. The 347 reserved characters of the URL syntax will be escaped as specified 348 in RFC 2396 [7] to ensure full conformance with the URI 349 Syntax. This means that the scheme specific part of the RealName 350 URL is the hex-encoding of the UTF-8 for that RealName. For 351 example, the RealName 'porsche boxster' becomes: 353 url:vnd.rn:porsche%20boxster 355 Security Considerations: 357 As with RealName URNs, the primary security risk in the use of 358 identifiers is that in some way the resource reached when 359 following a reference will not correspond to the resource 360 intended. The RealName system maintains a centralized scope of 361 authority, but the reliability of the mapping depends on the 362 security of the RealName mapping system. 364 NameSpace Ownership: 366 Centraal Corporation owns and manages the RealName repository 367 database and is the sole assigning authority for RealNames. The 368 RealNames are globally unique. 370 Interoperability considerations: 372 A RealName resolution service is provided on the internet at 373 http://www.realnames.com. The resolvers implement an HTTP/XML API 374 that can be used by a wide variety of clients to access resources 375 on the internet using the RealName URL. 377 Published specification: 379 This document. 381 Applications which use this URL scheme name: 383 Typical web applications can use RealName URLs as a way of 384 locating resources by their canonical RealName without invoking a 385 search service. 387 Additional information: 389 Centraal's Web site at http://www.centraal.com give a 390 comprehensive introduction of the RealName System. 392 Contact: 394 Nicolas Popp 395 Centraal Corporation 396 811 Hansen Way 397 PO Box 50750 398 Palo Alto CA 94303 0750 399 U.S.A. 400 Phone: (650)846-3615 401 Fax: (650)858-0454 402 Email: nico@centraal.com 404 Intend usage: 406 COMMON 408 Author/Change controller: 410 Nicolas Popp. 411 Centraal Corporation 413 4. Acknowledgments 415 Special thanks go to Yves Arrouye and Bill Washburn from Centraal 416 Corporation for comments on earlier drafts of this document. 418 5. References: 420 [1] Ryan Moats, "URN Syntax", RFC 2141, May 1997. 422 [2] Leslie L. Daigle, "URN Namespace Definition Mechanisms", 423 Internet Draft, August 1998. 425 [3] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource 426 Identifiers using the Domain Name System", RFC 2168, June 1997. 428 [4] Ron Daniel & Michael Mealling, Internet Draft, " URI Resolution 429 Services Necessary for URN Resolution", RFC 2168, March 1998. 431 [5] Martin J. Duerst, "Requirements for String Identity Matching and 432 String Indexing", World Wide Web Consortium Working Draft 433 10-July-1998. 435 [6] R. Petke, "Registration Procedures for URL Scheme Names", 436 Internet Draft, August 1998. 438 [7] T. Berners-Lee, "Uniform Resource Locators (URL)", RFC 1738, 439 August 1998. 441 7. Authors Addresses: 443 Nicolas Popp 444 Centraal Corporation 445 811 Hansen Way 446 PO Box 50750 447 Palo Alto CA 94303 0750 448 U.S.A. 449 Phone: (650)846-3615 450 Fax: (650)858-0454 451 Email: nico@centraal.com 453 Larry Masinter 454 Xerox Palo Alto Research Center 455 3333 Coyote Hill Road 456 Palo Alto, CA 94304 457 Phone: (650)812-4365 458 Fax: (650)812-4333 459 Email: masinter@parc.xerox.com 461 8. Copyright 463 Copyright (C) The Internet Society, 1997. All Rights Reserved. 465 This document and translations of it may be copied and furnished to 466 others, and derivative works that comment on or otherwise explain it 467 or assist in its implementation may be prepared, copied, published and 468 distributed, in whole or in part, without restriction of any kind, 469 provided that the above copyright notice and this paragraph are 470 included on all such copies and derivative works. However, this 471 document itself may not be modified in any way, such as by removing 472 the copyright notice or references to the Internet Society or other 473 Internet organizations, except as needed for the purpose of developing 474 Internet standards in which case the procedures for copyrights defined 475 in the Internet Standards process must be followed, or as required to 476 translate it into languages other than English. 478 The limited permissions granted above are perpetual and will not be 479 revoked by the Internet Society or its successors or assigns. 481 This document and the information contained herein is provided on an 482 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 483 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 484 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 485 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 486 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."