idnits 2.17.1 draft-ietf-urn-req-frame-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** 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 == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 30 instances of lines with control characters in the document. 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.) -- The document date (July 30, 1997) is 9738 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1736 (ref. '1') ** Obsolete normative reference: RFC 1738 (ref. '2') (Obsoleted by RFC 4248, RFC 4266) -- Duplicate reference: RFC1738, mentioned in '3', was also mentioned in '2'. ** Obsolete normative reference: RFC 1738 (ref. '3') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2141 (ref. '4') (Obsoleted by RFC 8141) == Outdated reference: A later version (-08) exists of draft-ietf-urn-nid-req-01 -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 18 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Karen R. Sollins 2 draft-ietf-urn-req-frame-03.txt MIT/LCS 3 Expires January 30, 1998 July 30, 1997 5 Architectural Principles of Uniform Resource Name Resolution 7 Status of this draft 8 This document is an Internet-Draft. Internet-Drafts are working 9 documents of the Internet Engineering Task Force (IETF), its 10 areas, and its working groups. Note that other groups may also 11 distribute working documents as Internet-Drafts. 13 Internet-Drafts are draft documents valid for a maximum of six 14 months and may be updated, replaced, or obsoleted by other 15 documents at any time. It is inappropriate to use Internet- 16 Drafts as reference material or to cite them other than as 17 ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check 20 the ``1id-abstracts.txt'' listing contained in the Internet- 21 Drafts Shadow Directories on ftp.is.co.za (Africa), 22 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 23 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 25 Abstract: 27 This document addresses the issues of the discovery of URN (Uniform 28 Resource Name) resolver services that in turn will directly translate 29 URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource 30 Characteristics). The document falls into three major parts, the 31 assumptions underlying the work, the guidelines in order to be a 32 viable Resolver Discovery Service or RDS, and a framework for 33 designing RDSs. The guidelines fall into three principle areas: 34 evolvability, usability, and security and privacy. An RDS that is 35 compliant with the framework will not necessarily be compliant with 36 the guidelines. Compliance with the guidelines will need to be 37 validated separately. 39 1. Introduction 41 The purpose of this document is to lay out the engineering criteria 42 for what we will call here a Resolver Discovery Service (RDS), a 43 service to help in the learning about URN (Uniform Resource Name) 44 resolvers. The term "resolver" is used in this document to indicate a 45 service that translates URNs to URLs (Uniform Resource Locators) or 46 URCs (Uniform Resource Characteristics). Some resolvers may provide 47 direct access to resources as well. An RDS helps in finding a 48 resolver to contact for further resolution. It is worth noting that 49 some RDS designs may also incorporate resolver functionality. This 50 function of URN resolution is a component of the realization of an 51 information infrastructure. In the case of this work, that 52 infrastructure is to be available, "in the Internet" or globally, and 53 hence the solutions to the problems we are addressing must be globally 55 - 1 - 56 scalable. In this document, we are focussing specifically on the 57 design of RDS schemes. 59 The Uniform Resource Identifier Working Group defined a naming 60 architecture, as demonstrated in a series of three RFCs 1736[1], 61 1737[2], and 1738[3]. Although several further documents are needed 62 to complete the description of that architecture, it incorporates 63 three core functions often associated with "naming": identification, 64 location, and mnemonics or semantics. By location, we mean 65 fully-qualified Domain Names or IP addresses, possibly extended with 66 TCP ports and/or local identifiers, such as pathnames. Names may 67 provide the ability to distinguish one resource from another, by 68 distinguishing their "names". Names may help to provide access to a 69 resource by including "location" information. Lastly, names may have 70 other semantic or mnemonic information that either helps human users 71 remember or figure out the names, or include other semantic 72 information about the resource being named. The URI working group 73 concluded that there was need for persistent, globally unique 74 identifiers, distinct from location or other semantic information; 75 these were called URNs. These "names" provide identity, in that if 76 two of them are "the same" (under some simple rule of 77 canonicalization), they identify the same resource. Furthermore, the 78 group decided that these "names" were generally to be for machine, 79 rather than human, consumption. 81 In contrast to URNs, one can imagine a variety human-friendly naming 82 (HFN) schemes supporting different suites of applications and user 83 communities. These will need to provide mappings to URNs in tighter 84 or looser couplings, depending on the namespace. It is these HFNs 85 that will be mnemonic, content-full, and perhaps mutable, to track 86 changes in use and semantics. They may provide nicknaming and other 87 aliasing, relative or short names, context sensitive names, 88 descriptive names, etc. Their definition is not part of this effort, 89 but will clearly play an important role in the long run. 91 URNs as described in RFC 1737 are defined globally; they are 92 ubiquitous in that a URN anywhere in any context identifies the same 93 resource. Given this requirement on URNs, one must ask about its 94 implication for an RDS. Does ubiquity imply a guarantee of RDS 95 resolution everywhere? Does ubiquity imply resolution to the same 96 information about resolution everywhere? In both cases the answer is 97 probably not. One cannot make global, systemic guarantees, except at 98 an expense beyond reason. In addition there may be policy reasons for 99 not resolving in the same way everywhere. It is quite possible that 100 the resolution of a URN to an instance of a resource may reach 101 different instances or copies under different conditions. Thus, 102 although a URN anywhere refers to the same resource, in some 103 environments under some conditions, and at different times, due to 104 either the vagaries of network conditions or policy controls a URN may 105 sometimes be resolvable and other times or places not. Ubiquitous 106 resolution cannot be assumed simply because naming is ubiquitous. On 107 the other hand wide deployment and usage will be an important feature 108 of any RDS design. 110 Within the URI community there has been a concept used frequently that 111 for lack of a better term we will call a _hint_. A hint is something 113 - 2 - 114 that helps in the resolution of a URN; in theory we map URNs to hints 115 as an interim stage in accessing a resource. In practice, an RDS may 116 map a URN directly into the resource itself if it chooses to. It is 117 very likely that there will be hints that are applicable to large sets 118 of URNs, for example, a hint that indicates that all URNs with a 119 certain prefix or suffix can be resolved by a particular resolver. A 120 hint may also have meta-information associated with it, such as an 121 expiration_time or certification of authenticity. We expect that 122 these will stay with a hint rather than being managed elsewhere. We 123 will assume in all further discussion of hints that they include any 124 necessary meta-information as well as the hint information itself. 125 Examples of hints are: 1) the URN of a resolver service that may 126 further resolve the URN, 2) the address of such a service, 3) a 127 location at which the resource was previously found. The defining 128 feature of hints is that they are only hints; they may be out of date, 129 temporarily invalid, or only applicable within a specific locality. 130 They do not provide a guarantee of access, but they probably will help 131 in the resolution process. We must assume that most resolutions of 132 URNs will be provided by the use of locally stored hints, because 133 maintaining a database of globally available, completely up-to-date 134 location information is infeasible for performance reasons. There are 135 a number of circumstances in which one can imagine that hints become 136 invalid, either because a resource has moved or because a different 137 URN resolver service has taken over the responsibility for resolution 138 of the URN. Hints may be found in a variety of places. It is 139 generally assumed that a well engineered system will maintain or cache 140 a set of hints for each URN at each location where that URN is found. 141 These may have been acquired from the owner of the resources, a 142 recommendation of the resource, or one of many other sources. In 143 addition, for those situations in which those hints found locally 144 fail, a well engineered system will provide a fall-back mechanism for 145 discovering further hints. It is this fall-back mechanism, an RDS, 146 that is being addressed in this document. As with all hints, there 147 can never be a guarantee that access to a resource will be available 148 to all clients, even if the resource is accessible to some. However, 149 an RDS is expected to work with reasonably high reliability, and, 150 hence, may result in increased response time. 152 The remainder of this document falls into three sections. The first 153 identifies several sets of assumptions underlying this work. There are 154 three general assumptions: 155 * URNs are persistent; 156 * URN assignment can be delegated; 157 * Decisions can be made independently, enabling isolation from decisions 158 of one's peers. 160 The next section lays out three central principles Resolver Discovery 161 Service design. For each of these, we have identified a number of 162 more specific guidelines that further define and refine the general 163 principle. This section is probably the most critical of the 164 document, because one must hold any proposed RDS scheme up against 165 these principles and corollary guidelines to learn whether or not it 166 is adequate. The three central principles can be summarized as: 167 1) An RDS must allow for evolution and evolvability; 168 2) Usability of an RDS with regard to each of the sets of constituents 169 involved in the identification and location or resources is paramount; 171 - 3 - 172 3) It is centrally important that the security and privacy needs of all 173 constituents be feasibly supported, to the degree possible. 174 Each of the three major subsections of the guidelines section begins 175 with a summary list of the more detailed guidelines identified in that 176 section. 178 The final section of the document lays out a framework for such RDSs. 179 The purpose of this last section is to bound the search space for RDS 180 schemes. The RDS designer should be aware that meeting the guidelines 181 is of primary importance; it is possible to meet them without 182 conforming to the framework. As will be discussed further in this 183 last section, designing within the framework does not guarantee 184 compliance, so compliance evaluation must also be part of the process 185 of evaluation of a scheme. 187 2. Assumptions 189 Based on previous internet drafts and discussion in both the URN BOFs 190 and on the URN WG mailing list, three major areas of assumptions are 191 apparent: longevity, delegation, and independence. Each will be 192 discussed separately. 194 The URN requirements[2] state that a URN is to be a "persistent 195 identifier". It is probably the case that nothing will last forever, 196 but in the time frame of resources, users of those resources, and the 197 systems to support the resources, the identifier should be considered 198 to be persistent or have a longer lifetime than those other entities. 199 There are two assumptions that are implied by longevity of URNs: 200 mobility and evolution. Mobility will occur because resources may 201 move from one machine to another, owners of resources may move among 202 organizations, or the organizations themselves may merge, partition, 203 or otherwise transforms themselves. The Internet is continually 204 evolving; protocols are being revised, new ones created, while 205 security policies and mechanisms evolve as well. These are only 206 examples. In general, we must assume that almost any piece of the 207 supporting infrastructure of URN resolution will evolve. In order to 208 deal with both the mobility and evolution assumptions that derive from 209 the assumption of longevity, we must assume that users and their 210 applications can remain independent of these mutating details of the 211 supporting infrastructure. 213 The second assumption is that naming and resolution authorities may 214 delegate some of their authority or responsibility; in both cases, the 215 delegation of such authority is the only known method of allowing for 216 the kind of scaling expected. It is important to note that a 217 significant feature of this work is the potential to separate name 218 assignment, the job of labelling a resource with a URN, from name 219 resolution, the job of discovering the resource given the URN. In 220 both cases, we expect multi-tiered delegation. There may be RDS 221 schemes that merge these two sets of responsibilities and delegation 222 relationships; by doing so, they bind together or overload two 223 distinctly different activities, thus probably impeding growth. 225 The third assumption is independence or isolation of one authority 226 from another and, at least to some extent, from its parent. When one 227 authority delegates some of its rights and responsibilities to another 229 - 4 - 230 authority, the delegatee can operate in that domain independently of 231 its peers and within bounds specified by the delegation, independently 232 of the delegator. This isolation is critically important in order to 233 allow for independence of policy and mechanism. 235 This third assumption has several corollaries. First, we assume that 236 the publisher of a resource can choose resolver services, 237 independently of choices made by others. At any given time, the owner 238 of a namespace may choose a particular URN resolver service for that 239 delegated namespace. Such a URN resolver service may be outside the 240 RDS service model, and only identified or located by the RDS service. 241 Second, it must be possible to make a choice among RDS services. The 242 existence of multiple RDS services may arise from the evolution of an 243 RDS service, or development of new ones. Although at any given time 244 there is likely to be only one or a small set of such services, the 245 number is likely to increase during a transition period from one 246 architecture to another. Thus, it must be assumed that clients can 247 make a choice among a probably very small set of RDSs. Third, there 248 must be independence in the choice about levels and models of security 249 and authenticity required. This choice may be made by the owner of a 250 naming subspace, in controlling who can modify hints in that subspace. 251 A naming authority may delegate this choice to the owners of the 252 resources named by the names it has assigned. There may be 253 limitations on this freedom of choice in order to allow other 254 participants to have the level of security and authenticity they 255 require, for example, in order to maintain the integrity of the RDS 256 infrastructure as a whole. Fourth, there is an assumption of 257 independence of choice of the rule of canonicalization of URNs within 258 a namespace, limited by any restrictions or constraints that may have 259 been set by its parent namespace. This is a choice held by naming 260 authorities over their own subnamespaces. Rules for canonicalization 261 will be discussed further in the framework section below. Thus, there 262 are assumptions of independence and isolation to allow for delegated, 263 independent authority in a variety of domains. 265 The modularity assumptions of delegation and isolation imply 266 independence of decision and implementation, leading to a 267 decentralization that provides a certain degree of safety from denial 268 of service. Based on these these assumptions in conjunction with that 269 of longevity and those for URLs and URNs as detailed in RFCs 1736 and 270 1737, we can now turn to the guidelines for an RDS. 272 3. Guidelines 274 The guidelines applying to an RDS center around three important design 275 principles in the areas of evolvability, usability, and security and 276 privacy. At its core the function of an RDS is to provide hints for 277 accessing a resource given a URN for it. These hints may range in 278 applicability from local to global, and from short-lived to 279 long-lived. They also may vary in their degree of verifiable 280 authenticity. While it may be neither feasible nor necessary that 281 initial implementations support every guideline, every implementation 282 must support evolution to systems that do support the guideline more 283 fully. 285 - 5 - 286 It is important to note that there are requirements, not applicable 287 specifically to an RDS that must also be met. A whole URN system will 288 consist of names in namespaces, the resolution information for them, 289 and the mapping from names in the namespaces to resolution information 290 (or hints). URNs themselves must meet the requirements of RFC 1737. 291 In addition, namespaces themselves must meet certain requirements as 292 described in RFC NNNN[5]. Although all these requirements and 293 guidelines are not described here, they must be supported to provide 294 an acceptable system. 296 Each section below begins with a summary of the points made in that 297 section. There is some degree of overlap among the areas, such as in 298 allowing for the evolution of security mechanisms, etc., and hence 299 issues may be addressed in more than one section. It is also 300 important to recognize that conformance with the guidelines will often 301 be subjective. As with most IETF guidelines and requirements, most of 302 these are not quantifiable and hence conformance is a judgment call 303 and a matter of degree. Lastly, the reader may find that some of them 304 are those of general applicability to distributed systems and some are 305 specific to URN resolution. Those of general applicability are 306 included for completeness and are not distinguished as such. 308 3.1 Evolution 310 The issues in the area of the first principle, that of evolvability, 311 are: 313 1.1) An RDS must be able to support scaling in at least three 314 dimensions: the number of resources for which URNs will be 315 required, the number of publishers and users of those 316 resources, and the complexity of the delegation, as authority 317 for resolution grows and possibly reflects delegation in 318 naming authority; 319 1.2) A hint resolution environment must support evolution of 320 mechanisms, specifically for: 321 * a growing set of URN schemes; 322 * new kinds local URN resolver services; 323 * new authentication schemes; 324 * alternative RDS schemes active simultaneously; 325 1.3) An RDS must allow the development and deployment of 326 administrative control mechanisms to manage human behavior with 327 respect to limited resources. 329 One of the lessons of the Internet that we must incorporate into the 330 development of mechanisms for resolving URNs is that we must be prepared 331 for change. Such changes may happen slowly enough to be considered 332 evolutionary modifications of existing services, or dramatically enough 333 to be considered revolutionary. They may permeate the Internet universe 334 bit by bit, living side by side with earlier services or they may take 335 the Internet by storm, causing an apparent complete transformation over 336 a short period of time. There are several directions in which we can 337 predict the need for evolution. At the very least, the community and 338 the mechanisms proposed should be prepared for these. 340 First, scaling is a primary issue in conjunction with evolution. The 341 number of users, both human and electronic, as well as the number of 343 - 6 - 344 resources will continue to grow exponentially for the near term, at 345 least. Hence the number of URNs will also increase similarly. In 346 addition, with growth in sheer numbers is likely to come growth in the 347 delegation of both naming authority and resolution authority. These 348 facts mean that an RDS design must be prepared to handle increasing 349 numbers of requests for inclusion, update and resolution, in a set of 350 RDS servers perhaps inter-related in more complex ways. This is not 351 to say that there will necessarily be more updates or resolutions per 352 URN; we cannot predict that at this time. But, even so, the 353 infrastructure may become more complex due to delegation, which may 354 (as can be seen in Section 4 on the framework) lead to more complex 355 rules for rewriting or extracting terms for staged resolution. Any 356 design is likely to perform less well above some set of limits, so it 357 is worth considering the growth limitations of each design 358 alternative. 360 Second, we expect there to be additions and changes to the mechanisms. 361 The community already understands that there must be a capacity for 362 new URN schemes, as described in [5]. A URN scheme will define a set 363 of URNs that meet the URN requirements[2], but may have further 364 constraints on the internal structure of the URN. The intention is 365 that URN schemes can be free to specify parts of the URN that are left 366 opaque in the larger picture. In fact, a URN scheme may choose to 367 make public or keep private the algorithms for any such "opaque" part 368 of the URN. In any case, we must be prepared for a growing number of 369 URN schemes. 371 Often in conjunction with a new URN scheme, but possibly independently 372 of any particular URN scheme, new kinds of resolver services may 373 evolve. For example, one can imagine a specialized resolver service 374 based on the particular structure of ISBNs that improves the 375 efficiency of finding documents given their ISBNs. Alternatively, one 376 can also imagine a general purpose resolver service that trades 377 performance for generality; although it exhibits only average 378 performance resolving ISBNs, it makes up for this weakness by 379 understanding all existing URN schemes, so that its clients can use 380 the same service to resolve URNs regardless of naming scheme. In this 381 context, there will always be room for improvement of services, 382 through improved performance, better adaptability to new URN schemes, 383 or lower cost, for example. New models for URN resolution will evolve 384 and we must be prepared to allow for their participation in the 385 overall resolution of URNs. 387 If we begin with one overall plan for URN resolution, into which the 388 enhancements described above may fit, we must also be prepared for an 389 evolution in the authentication schemes that will be considered either 390 useful or necessary in the future. There is no single globally 391 accepted authentication scheme, and there may never be one. Even if 392 one does exist at some point in time, we must always be prepared to 393 move on to newer and better schemes, as the old ones become too easily 394 spoofed or guessed. 396 In terms of mechanism, although we may develop and deploy a single RDS 397 scheme initially, we must be prepared for that top level model to 398 evolve. Thus, if the RDS model supports an apparently centralized 399 (from a policy standpoint) scheme for inserting and modifying 401 - 7 - 402 authoritative information, over time we must be prepared to evolve to 403 a different model, perhaps one that has a more distributed model of 404 authority and authenticity. If the model has no core but rather a 405 cascaded partial discovery of information, we may find that this 406 becomes unmanageable with an increase in scaling. Whatever the model, 407 we must be prepared for it to evolve with changes in scaling, 408 performance, and policy constraints such as security and cost. 410 The third evolutionary issue is even more mechanical than the others. 411 At any point in time, the community is likely to be supporting a 412 compromise position with respect to resolution. We will probably be 413 operating in a situation balanced between feasibility and the ideal, 414 perhaps with policy controls used to help stabilize use of the 415 service. Ideally, the service would be providing exactly what the 416 customers wanted and they in turn would not request more support than 417 they need, but it seems extremely unlikely. Since we will almost 418 always be in a situation in which some service provision resources 419 will be in short supply, some form of policy controls will generally 420 be necessary. Some policy controls may be realized as mechanisms 421 within the servers or in the details of protocols, while others may 422 only be realized externally to the system. For example, suppose hint 423 entries are being submitted in such volume that the hint servers are 424 using up their excess capacity and need more disk space. Two 425 suggestions for policy control are pricing and administrative. As 426 technology changes and the balance of which resources are in short 427 supply changes, the mechanisms and policies for controlling their use 428 must evolve as well. 430 3.2 Usability 432 To summarize, the usability guidelines fall into three areas based on 433 participation in hint management and discovery: 435 2.1) The publisher 436 2.1.1) URN to hint resolution must be correct and efficient with 437 very high probability; 438 2.1.2) Publishers must be able to select and move among URN 439 resolver services to locate their resources; 440 2.1.3) Publishers must be able to arrange for multiple access 441 points for their location information; 442 2.1.4) Publishers should be able to provide hints with varying 443 lifetimes; 444 2.1.5) It must be relatively easy for publishers to specify to 445 the management and observe their hint information as well 446 as any security constraints they need for their hints. 447 2.2) The client 448 2.2.1) The interface to the RDS must be simple, effective, and 449 efficient; 450 2.2.2) The client and client applications must be able to 451 understand the information stored in and provided by the 452 RDS easily, in order to be able to make informed choices. 453 2.3) The management 454 2.3.1) The management of hints must be as unobtrusive as 455 possible, avoiding using too many network resources; 456 2.3.2) The management of hints must allow for administrative 457 controls that encourage certain sorts of behavior deemed 459 - 8 - 460 necessary to meet other requirements; 461 2.3.3) The configuration and verification of configuration of 462 individual RDS servers must be simple enough not to 463 discourage configuration and verification. 465 Usability can be evaluated from three distinct perspectives: those of a 466 publisher wishing to make a piece of information public, those of a 467 client requesting URN resolution, and those of the provider or manager 468 of resolution information. We will separately address the usability 469 issues from each of these three perspectives. 471 It is worth noting that there are two additional sorts of participants 472 in the whole naming process, as discussed in the URN WG. They are the 473 naming authorities which choose and assign names, and the authors who 474 include URNs in their resources. These two are not relevant to the 475 design of an RDS and hence are not discussed further here. 477 3.2.1 The Publisher 479 The publisher must be able to make URNs known to potential customers. 480 From the perspective of a publisher, it is of primary importance that 481 URNs be correctly and efficiently resolvable by potential clients with 482 very high probability. Publishers stand to gain from long-lived URNs, 483 since they increase the chance that references continue to point to 484 their published resources. 486 The publisher must also be able to choose easily among a variety of 487 potential services that might translate URNs to location information. 488 In order to allow for this mobility among resolvers, the RDS 489 architecture must support such transitions, within policy control 490 bounds. It is worth noting that although multiple listing services 491 are available in telephone books, they are generally accompanied by a 492 fee. There is nothing preventing there being fees collected for 493 similar sorts of services with respect to URNs. 495 The publisher must be able to arrange for multiple access points to a 496 published resource. For this to be useful, resolver services should 497 be prepared to provide different resolution or hint information to 498 different clients, based on a variety of information including 499 location and the various access privileges the client might have. It 500 is important to note that this may have serious implications for 501 caching this information. For example, companies might arrange for 502 locally replicated copies of popular resources, and would like to 503 provide access to the local copies only for their own employees. This 504 is distinct from access control on the resource as a whole, and may be 505 applied differently to different copies. 507 The publisher should be able to provide both long and short term 508 location information about accessing the resource. Long term 509 information is likely to be such information as the long term address 510 of a resource itself or the location or identity of a resolver service 511 with which the publisher has a long term relationship. One can 512 imagine that the arrangement with such a long term "authoritative" 513 resolver service might be a guarantee of reliability, resiliency to 514 failure, and atomic updates. Shorter term information is useful for 515 short term changes in services or to avoid short lived congestion or 517 - 9 - 518 failure problems. For example, if the actual repository of the 519 resource is temporarily inaccessible, the resource might be made 520 available from another repository. This short term information can be 521 viewed as temporary refinements of the longer term information, and as 522 such should be more easily and quickly made available, but may be less 523 reliable. Some RDS designs may not distinguish between these two 524 extremes. 526 Lastly, the publishers will be the source of much hint information 527 that will be stored and served by the manager of the infrastructure. 528 Despite the fact that many publishers will not understand the details 529 of the RDS mechanism, it must be easy and straightforward for them to 530 install hint information. This means that in general any one who 531 wishes to publish and to whom the privilege of resolution has been 532 extended through delegation, can do so. The publisher must be able 533 not only to express hints, but also to verify that what is being 534 served by the manager is correct. Furthermore, to the extent that 535 there are security constraints on hint information, the publisher must 536 be able to both express them and verify compliance with them easily. 538 3.2.2 The Client 540 From the perspective of the client, simplicity and usability are 541 paramount. Of critical importance to serving clients effectively is 542 that there be an efficient protocol through which the client can acquire 543 hint information. Since resolving the name is only the first step on 544 the way to getting access to a resource, the amount of time spent on it 545 must be minimized. 547 Furthermore, it will be important to be able to build simple, standard 548 interfaces to the RDS so that both the client and applications on the 549 client's behalf can interpret hints and subsequently make informed 550 choices. The client, perhaps with the assistance of the application, 551 must be able to specify preferences and priorities and then apply them. 552 If the ordering of hints is only partial, the client may become directly 553 involved in the choice and interpretation of them and hence they must be 554 understandable to that client. On the other hand, in general it should 555 be possible to configure default preferences, with individual 556 preferences viewed as overriding any defaults. 558 From the client's perspective, although URNs will provide important 559 functionality, the client is most likely to interact directly only with 560 human friendly names (HFNs). As in direct human interaction (not 561 computer mediated), the sharing of names will be on a small, private, or 562 domain specific scale. HFNs will be the sorts of references and names 563 that are easy to remember, type, choose among, assign, etc. There will 564 also need to be a number of mechanisms for mapping HFNs to URNs. Such 565 services as "yellow pages" or "search tools" fall into this category. 566 Although we are mentioning HFNs here, it is important to recognize that 567 HFNs and the mappings from HFNs to URNs is and must remain a separate 568 functionality from an RDS. Hence, although HFNs will be critical to 569 clients, they do not fall into the domain of this document. 571 - 10 - 572 3.2.3 The Management 574 Finally, we must address the usability concerns with respect to the 575 management of the hint infrastructure itself. What we are terming 576 "management" is a service that is distinct from publishing; it is the 577 core of an RDS. It involves the storage and provision of hints to the 578 clients, so that they can find published resources. It also provides 579 security with respect to name resolution to the extent that there is a 580 commitment for provision of such security; this is addressed in 581 Section 3.3 below. 583 The management of hints must be as unobtrusive as possible. First, its 584 infrastructure (hint storage servers and distribution protocols) must 585 have as little impact as possible on other network activities. It must 586 be remembered that this is an auxiliary activity and must remain in the 587 background. 589 Second, in order to make hint management feasible, there may need to 590 be a system for administrative incentives and disincentives such as 591 pricing or legal restrictions. Recovering the cost of running the 592 system is only one reason for levying charges. The introduction of 593 payments often has an impact on social behavior. It may be necessary 594 to discourage certain forms of behavior that when out of control have 595 serious negative impact on the whole community. At the same time, any 596 administrative policies should encourage behavior that benefits the 597 community as a whole. Thus, for example, a small one-time charge for 598 authoritatively storing a hint will encourage conservative use of 599 hints. If we assume that there is a fixed cost for managing a hint, 600 then the broader its applicability across the URN space, the more cost 601 effective it is. That is, when one hint can serve for a whole 602 collection of URNs, there will be an incentive to submit one general 603 hint over a large number of more specific hints. Similar policies can 604 be instituted to discourage the frequent changing of hints. In these 605 ways and others, behavior benefitting the community as a whole can be 606 encouraged. 608 Lastly, symmetric to issues of usability for publishers, it must also be 609 simple for the management to configure the mapping of URNs to hints. It 610 must be easy both to understand the configuration and to verify that 611 configuration is correct. With respect to management, this issue may 612 have an impact not only on the information itself but also on how it is 613 partitioned among network servers that collaboratively provide the 614 management service or RDS. For example, it should be straightforward to 615 bring up a server and verify that the data it is managing is correct. 616 Although this is not a guideline, it is worth nothing that since we are 617 discussing a global and probably growing service, encouraging volunteer 618 participants suggests that, as with the DNS, such volunteers can feel 619 confident about the service they are providing and its benefit to both 620 themselves and the rest of the community. 622 3.3 Security and Privacy 624 In summary, security and privacy guidelines can be identified as some 625 degree of protection from threats. The guidelines that fall under 626 this third principle, that of security, are all stated in terms of 627 possibilities or options for users of the service to require and 629 - 11 - 630 utilize. Hence they address the availability of functionality, but 631 not for the use of it. We recognize that all security is a matter of 632 degree and compromise. These may not satisfy all potential customers, 633 and there is no intention here to prevent the building of more secure 634 servers with more secure protocols to suit their needs. These are 635 intended to satisfy the needs of the general public. 637 3.1) It must be possible to create authoritative versions of a hint 638 with access-to-modification privileges controlled; 639 3.2) It must be possible to determine the identity of servers or 640 avoid contact with unauthenticated servers; 641 3.3) It must be possible to reduce the threat of denial of service 642 by broad distribution of information across servers. 643 3.4) It must be possible within the bounds of organizational 644 policy criteria to provide at least some degree of privacy 645 for traffic. 646 3.5) It must be possible for publishers to keep private certain 647 information such as an overall picture of the resources they 648 are publishing and the identity of their clients; 649 3.6) It must be possible for publishers to be able to restrict 650 access to the resolution of the URNs for the resources they 651 publish, if they wish. 653 When one discusses security, one of the primary issues is an enumeration 654 of the threats being considered for mitigation. The tradeoffs often 655 include cost in money and computational and communications resources, 656 ease of use, likelihood of use, and effectiveness of the mechanisms 657 proposed. With this in mind, let us consider a set of threats. 659 Voydock and Kent[7] provide a useful catalog of potential threats. Of 660 these the passive threats to privacy or confidentiality and the active 661 threats of authenticity and integrity are probably the most important 662 to consider here. To the extent that spurious association causes 663 threats to the privacy, authenticity, or integrity with respect to 664 information within servers managing data, it is also important. 665 Denial of service is probably the most difficult of these areas of 666 threats both to detect and to prevent, and we will therefore set it 667 aside for the present as well, although it will be seen that solutions 668 to other problems will also mitigate some of the problems of denial of 669 service. Furthermore, because this is intended to be provide a global 670 service to meet the needs of a variety of communities, the engineering 671 tradeoffs will be different for different clients. Hence the 672 guidelines are stated in terms of, "It must be possible..." It is 673 important to note that the information of concern here is hint 674 information, which by nature is not guaranteed to be correct or 675 up-to-date; therefore, it is unlikely to be worth putting too much 676 expense into the correctness of hints, because there is no guarantee 677 that they are still correct anyway. The exact choice of degree of 678 privacy, authenticity, and integrity must be determined by the needs 679 of the client and the availability of services from the server. 681 To avoid confusion it is valuable to highlight the meanings of terms 682 that have different meanings in other contexts. In this case, the 683 term "authoritative" as it is used here connotes the taking of an 684 action or stamp of approval by a principal (again in the security 685 sense) that has the right to perform such an act of approval. It has 687 - 12 - 688 no implication of correctness of information, but only perhaps an 689 implication of who claimed it to be correct. In contrast, the term is 690 often also used simply to refer to a primary copy of a piece of 691 information for which there may also be secondary or cached copies 692 available. In this discussion of security we use the former meaning, 693 although it may also be important to be able to learn about whether a 694 piece of information is from a primary source or not and request that 695 it be primary. This second meaning arises elsewhere in the document 696 and is so noted there. 698 It is also important to distinguish various possible meanings for 699 "access control". There are two areas in which distinctions can be 700 made. First, there is the question of the kind of access control that 701 is being addressed, for example, in terms of hints whether it is read 702 access, read and modify access, or read with verification for 703 authenticity. Second, there is the question of to what access is being 704 controlled. In the context of naming it might be the names themselves 705 (not the case for URNs), the mapping of URNs to hints (the business of 706 an RDS), the mapping of URNs to addresses (not the business of an RDS as 707 will be discussed below in terms of privacy), or the resource itself 708 (unrelated to naming or name resolution at all). We attempt to be clear 709 about what is meant when using "access control". 711 There is one further issue to address at this point, the distinction 712 between mechanism and policy. In general, a policy is realized by means 713 of a set of mechanisms. In the case of an RDS there may be policies 714 internal to the RDS that it needs to have supported in order to do its 715 business as it sees fit. Since, in general it is in the business of 716 storing and distributing information, most of its security policies may 717 have to do with maintaining its own integrity, and are rather limited. 718 Beyond that, to the degree possible, it should impose no policy on its 719 customers, the publishers and users. It is they that may have policies 720 that they would like supported by the RDS. To that end, an RDS should 721 provide a spectrum of "tools" or mechanisms that the customers can cause 722 to be deployed on their behalf to realize policies. An RDS may not 723 provide all that is needed by a customer. A customer may have different 724 requirements within his or her administrative bounds than outside. 725 Thus, "it must be possible..." captures the idea that the RDS must 726 generally provide the tools to implement policies as needed by the 727 customers. 729 The first approach to URN resolution is to discover local hints. In 730 order for hints to be discovered locally, they will need to be as 731 widely distributed to what is considered to be local for every locale. 732 The drawback of such wide distribution is the wide distribution of 733 updates, causing network traffic problems or delays in delivering 734 updates. An alternative model would concentrate hint information in 735 servers, thus requiring that update information only be distributed to 736 these servers. In such a model the vulnerable points are the sources 737 of the information and the distribution network among them. Attackers 738 on the integrity of the information stored in a server may come in the 739 form of masquerading as the owner or the server of the information. 740 Wide replication of information among servers increases the difficult 741 of masquerading at all the locations of the information as well as 742 reducing the threat of denial service. These lead us to three 743 identifiable guidelines for our security model: 745 - 13 - 746 * ACCESS CONTROL ON HINTS: It must be possible to create an 747 authoritative version of each hint with change control limited only 748 to those principals with the right to modify it. The choice of who 749 those principals are or whether they are unlimited must be made by 750 the publisher of a hint. 752 * SERVER AUTHENTICITY: Servers and clients must be able to learn the 753 identity of the servers with which they communicate. This will be a 754 matter of degree and it is possible that there will be more 755 trustworthy, but less accessible servers, supported by a larger 756 cluster of less authenticatable servers that are more widely 757 available. In the worst case, if the client receives what appears to 758 be unvalidated information, the client should assume that the hint 759 may be inaccurate and confirmation of the data might be sought from 760 more reliable but less accessible sources. 762 * SERVER DISTRIBUTION: Broad availability will provide resistance to 763 denial of service. It is only to the extent that the services are 764 available that they provide any degree of trustworthiness. In 765 addition, the distribution of services will reduce vulnerability 766 of the whole community, by reducing the trust put in any single 767 server. This must be mitigated by the fact that to the extent trust 768 is based on a linked set of servers, if any one fails, the whole 769 chain of trust fails; the more elements there are in such a chain, 770 the more vulnerable it may become. 772 Privacy can be a double-edged sword. For example, on one hand, an 773 organization may consider it critically important that its competitors 774 not be able to read its traffic. On the other hand, it may also 775 consider it important to be able to monitor exactly what its employees 776 are transmitting to and from whom, for a variety of reasons such as 777 reducing the probability that its employees are giving or selling the 778 company's secrets to verifying that employees are not using company 779 resources for private endeavor. Thus, although there are likely to be 780 needs for privacy and confidentiality, what they are, who controls 781 them and how, and by what mechanisms vary widely enough that it is 782 difficult to say anything concrete about them here. 784 The privacy of publishers is much easier to safeguard. Since they are 785 trying to publish something, in general privacy is probably not desired. 786 However, publishers do have information that they might like to keep 787 private: information about who their clients are, and information about 788 what names exist in their namespace. The information about who their 789 clients are may be difficult to collect depending on the implementation 790 of the resolution system. For example, if the resolution information 791 relating to a given publisher is widely replicated, the hits to _each_ 792 replicated copy would need to be recorded. Of course, determining if a 793 specific client is requesting a given name can be approached from the 794 other direction, by watching the client as we saw above. 796 There are likely to be some publishers publishing for a restricted 797 audience. To the extent they want to restrict access to a resource, 798 that is the responsibility of the repository providing and restricting 799 access to the resource. If they wish to keep the name and hints for a 800 resource private, a public RDS may be inadequate for their needs. In 802 - 14 - 803 general, it is intended for those who want customers to find their 804 resources in an unconstrained fashion. 806 The final privacy issue for publishers has to do with access control 807 over URN resolution. This issue is dependent on the implementation of 808 the publisher's authoritative (in the sense of "primary) URN resolver 809 server. URN resolver servers can be designed to require proof of 810 identity in order to be issued resolution information; if the client 811 does not have permission to access the URN requested, the service denies 812 that such a URN exists. An encrypted protocol can also be used so that 813 both the request and the response are obscured. Encryption is possible 814 in this case because the identity of the final recipient is known (i.e. 815 the URN server). Thus, access control over URN resolution can and 816 should be provided by resolver servers rather than an RDS. 818 4. The Framework 820 With these assumptions and guidelines in mind, we conclude with a 821 general framework within which RDS designs may fall. As stated 822 earlier, although this framework is put forth as a suggested guide for 823 RDS designers, compliance with it will in no way guarantee compliance 824 with the guidelines. Such an evaluation must be performed separately. 825 All such lack of compliance should be clearly documented. 827 The design of the framework is based on the syntax of a URN as 828 documented in RFC-2141[4]. This is: 830 URN:: 832 where URN: is a prefix on all URNs, NID is the namespace identifier, and 833 NSS is the namespace specific string. The prefix identifies each URN as 834 such. The NID determines the general syntax for all URNs within its 835 namespace. The NSS is probably partitioned into a set of delegated and 836 subdelegated namespaces, and this is possibly reflected in further 837 syntax specifications. In more complex environments, each delegated 838 namespace will be permitted to choose the syntax of the variable part of 839 the namespace that has been delegated to it. In simpler namespaces, the 840 syntax will be restricted completely by the parent namespace. For 841 example, although the DNS does not meet all the requirements for URNs, 842 it has a completely restricted syntax, such that any further structuring 843 must be done only by adding further refinements to the left, maintaining 844 the high order to low order, right to left structure. A delegated 845 syntax might be one in which a host is named by the DNS, but to the 846 right of that and separated by an "@" is a string whose internal 847 ordering is defined by the file system on the host, which may be defined 848 high order to low order, left to right. Of course, much more complex 849 and nested syntaxes should be possible, especially given the need to 850 grandfather namespaces. In order to resolve URNs, rules will be needed 851 for two reasons. One is simply to canonicalize those namespaces that do 852 not fall into a straightforward (probably right to left or left to 853 right) ordering of the components of a URN, as determined by the 854 delegated naming authorities involved. It is also possible that rules 855 will be needed in order to derive from URNs the names of RDS servers to 856 be used in stages. 858 The NID defines a top level syntax. This syntax will determine whether 860 - 15 - 861 the NID alone or in conjunction with some extraction from the NSS (for 862 the top level naming authority name) is to be used to identify the first 863 level server to be contacted. At each stage of the lookup either a new 864 rule for generating the strings used in yet another lookup (the strings 865 being the identity of another RDS server and possibly a string to be 866 resolved if it is different than the original URN) or a reference 867 outside the RDS to a URN resolver service, sidestepping any further use 868 of the RDS scheme. Figure 1 depicts this process. 870 URN: 871 | 872 | 873 | 874 | 875 v 876 +-------------------+ 877 |Global NID registry| 878 +-------------------+ 879 | 880 | 881 | 882 (return rule or URN resolver service reference) 883 | 884 +----------------------------------+ 885 | | 886 +->(apply rule to determine RDS server) | 887 | | | 888 | | | 889 | | | 890 | +----------+ | 891 | |RDS server| +-----------------+ 892 | +----------+ | 893 | | | v 894 | | | (set of choices) 895 | | +----+----------(...)--------+ 896 | (rule) | | 897 | | | | 898 | | | | 899 +------+ | | 900 v v 901 +----------+ +----------+ 902 |URN | |URN | 903 |resolver | |resolver | 904 |service | |service | 905 +----------+ +----------+ 907 Figure 1: An RDS framework 909 There are several points worth noting about the RDS framework. First, 910 it leaves open the determination of the protocols, data organization, 911 distribution and replication needed to support a particular RDS scheme. 912 Second, it leaves open the location of the computations engendered by 914 - 16 - 915 the rules. Third, it leaves open the possibility that partitioning 916 (distribution) of the RDS database need not be on the same boundaries as 917 the name delegation. This may seem radical to some, but if the 918 information is stored in balanced B-trees for example, the partitioning 919 may not be along those naming authority delegation boundaries (see 920 [6]). Lastly, it leaves open access to the Global NID Registry. Is 921 this distributed to every client, or managed in widely distributed 922 servers? 924 One concept that has not been addressed in Figure 1 is that there may be 925 more than one RDS available at any given time, in order to allow for 926 evolution to new schemes. Thus, the picture should probably look more 927 like Figure 2. 929 URN:: 930 | 931 | 932 +-----------+-------(...)-------+ 933 | | 934 | | 935 | | 936 v v 937 +---------------------+ +---------------------+ 938 |Global NID registry 1| |Global NID registry N| 939 +---------------------+ +---------------------+ 940 . . 941 . . 942 . . 944 Figure 2: More than one co-existing RDS scheme 946 If we are to support more than one co-existing RDS scheme, there will 947 need to be coordination among them with respect to storage and 948 propagation of information and modifications. The issue is that 949 generally it should be assumed that all information should be available 950 through any operational RDS scheme. One cannot expect potential 951 publishers to submit updates to more than one RDS scheme. Hence there 952 will need to be a straightforward mapping of information from one to the 953 other of these schemes. It is possible that that transformation will 954 only go in one direction, because a newer RDS service is replacing an 955 older one, which is not kept up to date, in order to encourage transfer 956 to the newer one. Thus, at some point, updates may be made only to the 957 newer one and not be made available to the older one, as is often done 958 with library catalogs. 960 This framework is presented in order to suggest to RDS scheme designers 961 a direction in which to start designing. It should be obvious to the 962 reader that adherence to this framework will in no way guarantee 963 compliance with the guidelines or even the assumptions described in 964 Sections 2 and 3. These must be reviewed independently as part of the 965 design process. There is no single correct design that will conform to 966 these guidelines. Furthermore, it is assumed that preliminary proposals 968 - 17 - 969 may not meet all the guidelines, but should be expected to itemized and 970 justify any lack of compliance. 972 5. Acknowledgments 974 Foremost acknowledgment for this document goes to Lewis Girod, as my 975 co-author on a preliminary URN requirements document and for his 976 insightful comments on this version of the document. Thanks also go 977 to Ron Daniel especially for his many comments on my writing. In 978 addition, I recognize the contributors to a previous URN framework 979 document, the "Knoxville" group. There are too many of you to 980 acknowledge here individually, but thank you. Finally, I must thank 981 the contributors to the URN working group and mailing list 982 (urn-ietf@bunyip.com), for your animated discussions on these and 983 related topics. 985 6. References 987 [1] Kunze, J., "Functional Recommendations for Internet Resource 988 Locators", RFC 1736, February, 1995. 990 [2] Sollins, K. and Masinter, L., "Functional Requirements for Uniform 991 Resource Names", RFC 1738, December, 1994. 993 [3] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource 994 Locators (URL)", RFC 1738, December, 1994. 996 [4] Moats, R., "URN Syntax", RFC 2141, May 1997. 998 [5] Iannella, R. and Faltstrom, P., "Namespace Identifier Requirements 999 for URN Services," currently draft-ietf-urn-nid-req-01.txt. Intended 1000 to become an information rfc by the URN working group. 1002 [6] Slottow, E.G., "Engineering a Global Resolution Service," 1003 MIT-LCS-TR712, June, 1997. Currently available as 1004 or 1005 . 1007 [7] Voydock, V. L., and Kent, S. T., "Security Mechanisms in 1008 High-Level Protocols", ACM Computing Surveys, v. 15, No. 2, June, 1009 1983, pp. 135-171. 1011 7. Contact information: 1013 Karen Sollins 1014 MIT Laboratory for Computer Science 1015 545 Technology Sq. 1016 Cambridge, MA 02139 1018 Tel: +1 617 253 6006 1019 Email: sollins@lcs.mit.edu 1021 This Internet Draft expires on December 4, 1997. 1023 - 18 -