idnits 2.17.1 draft-ietf-urn-req-frame-00.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-04-23) 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 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 32 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 (November 26, 1996) is 10010 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 ** Obsolete normative reference: RFC 1738 (ref. 'RFC1737') (Obsoleted by RFC 4248, RFC 4266) -- Duplicate reference: RFC1738, mentioned in 'RFC1738', was also mentioned in 'RFC1737'. ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) Summary: 16 errors (**), 0 flaws (~~), 1 warning (==), 3 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-00.txt MIT/LCS 3 Expires May 26, 1997 November 26, 1996 5 Requirements and a Framework for URN Resolution Systems 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 local URN 28 resolution services that in turn will directly translate URNs into 29 URLs and URCs. The document falls into three major parts, the 30 assumptions underlying the work, the requirements in order to be a 31 viable URN-resolution-service discovery service or UDS, and a 32 framework for designing UDSs. The requirements fall into three major 33 areas: evolvability, usability, and security and privacy. A UDS that 34 is compliant with the framework will not necessarily be compliant with 35 the requirements. Compliance with the requirements will need to be 36 validated separately. 38 1. Introduction 40 The purpose of this document is to lay out the engineering criteria for 41 what we will call here a URN-resolution-service discovery service (UDS). 42 __________ 44 Acknowledgments 46 Foremost acknowledgment for this document goes to Lewis Girod, as my 47 co-author on a previous URN requirements document and for his insightful 48 comments on this version of the document. In addition, I recognize the 49 contributors to a previous URN framework document, the "Knoxville" 50 group. There are too many of you to acknowledge here individually, but 51 thank you. Finally, I must thank the contributors to the URN working 52 group mailing list (urn-ietf@bunyip.com), for their animated discussions 53 on these and related topics. 55 URN Resolution Requirements Page 1 56 This is a component of the realization of an information infrastructure. 57 In the case of this work, that infrastructure is to be available, "in 58 the Internet" or globally, and hence the solutions to the problems we 59 are addressing must globally scalable. In this work, we are focussing 60 specifically on naming of resources and resolution of those names to the 61 exclusion of other problems such as typing, resource access and 62 availability, security of the resources, etc. Those are all important 63 problems, but not part of this effort. 65 The Uniform Resource Identifier Working Group defined a naming 66 architecture, as demonstrated in a series of three RFCs 1736[RFC1736], 67 1737{RFC1737}, and 1738[RFC1738]. Although several further documents 68 are needed to complete the description of that architecture, it 69 incorporates three core functions often associated with "naming": 70 identification, location, and mnemonics or semantics. Names may provide 71 the ability to distinguish one resource from another, by distinguishing 72 their "names". Names may help to provide access to a resource by 73 including "location" information. Lastly, names may have other semantic 74 or mnemonic information that either helps human users remember or figure 75 out the names, or include other semantic information about the resource 76 being named. The URI working group concluded that there was need for 77 persistent, globally unique identifiers, distinct from location or other 78 semantic information; these "names" provide identity, in that if two of 79 them are "the same" (under some simple rule of canonicalization), they 80 identify the same resource. Furthermore, the group decided that these 81 "names" were generally to be for machine, rather than human consumption. 82 One can imagine a variety human-friendly naming (HFN) schemes supporting 83 different suites of applications and user communities. These will need 84 to provide mappings to URNs in tighter or looser couplings, depending on 85 the namespace. It is these that will be mnemonic, content-full, and 86 perhaps mutable, to track changes in use and semantics. They may 87 provide nicknaming and other aliasing, relative or short names, context 88 sensitive names, descriptive names, etc. The URI naming architecture as 89 described in the introductions to RFCs 1736 and 1737 lays out three 90 sorts of components to the naming architecture: identifiers called 91 Uniform Resource Names (URNs), locators called Uniform Resource Locators 92 (URLs) and semantic meta-information called Uniform Resource 93 Characteristics (URCs). This document focusses on part of the problem 94 of the translation from URN to URL and/or URC. 96 Within the URI community there has been a concept used frequently that 97 for lack of a better term we will call a _hint_. A hint is something 98 that helps in the resolution of a URN. Examples of hints are: 1) the 99 name of a resolution service that may further resolve the URN, 2) the 100 address of such a service, 3) a location at which the resource was 101 previously found. The defining feature of hints is that they are only 102 hints; they may be out of date, temporarily invalid, or only applicable 103 within a specific locality. They do not provide a guarantee of access, 104 but they probably will help in the resolution process. Wemust assume 105 that most resolutions of URNs will be provided by the use of locally 106 stored hints, because maintaining a database of globally available, 107 completely up-to-date location information is infeasible for performance 108 reasons. There are a number of circumstances in which one can imagine 109 that hints become invalid, either because a resource has moved or 110 because a different URN resolution service has taken over the 112 URN Resolution Requirements Page 2 113 responsibility for resolution of the URN. Hints may be found in a 114 variety of places. It is generally assumed that a well engineered 115 system will maintain a set of hints for each URN at each location where 116 that URN is found. In addition, for those situations in which those 117 hints found locally fail, a well-engineered system will provide a 118 fall-back mechanism for discovering further hints. It is this fall-back 119 mechanism, a UDS, that is being addressed in this document. As with all 120 hints, there can never be a guarantee that access to a resource will be 121 available to all clients, even if the resource is accessible to some. 122 However, a UDS is expected to work with reasonably high reliability, 123 and, hence, may result in increased response time. The remainder of 124 this document falls into three sections. The first identifies several 125 sets of assumptions underlying this work. The next lays out the 126 requirements for a URN-resolution-service discovery service. This 127 section is probably the most critical of the document, because it is 128 this that provides the metric for whether or not a proposed scheme for a 129 UDS is adequate or not. For the reader short on time, each of the three 130 major subsections of the requirements section concludes with a summary 131 list of the requirements identified in that section. The final section 132 of the document lays out a framework for such UDSs. The purpose of this 133 last section is to bound the search space for UDS schemes. One must be 134 careful not to assume that because a UDS scheme fits within the 135 framework that it necessarily meets the requirements. As will be 136 discussed further in this last section, designing within the framework 137 does not guarantee compliance, so compliance evaluation must also be 138 part of the process of evaluation of a scheme. 140 2. Assumptions 142 Based on previous internet drafts and discussion in both the URN BOFs 143 and on the URN WG mailing list, three major areas of assumptions are 144 apparent: longevity, delegation, and independence. Each will be 145 discussed separately. 147 The URN requirements state that a URN is to be a "persistent 148 identifier". It is probably the case that nothing will last forever, 149 but in the time frame of resources, users of those resources, and the 150 systems to support the resources, the identifier should be considered to 151 be persistent or have a longer lifetime than those other entities. 152 There are two assumptions that are implied by longevity of URNs: 153 mobility and evolution. "Mobility" assumes that. everything will move 154 over the life of a URN. For example, resources will move from one 155 machine to another, because individual machines have a much shorter 156 lifetime than resources, generally measured in a number of years less 157 than a decade. Owners of resources may move and wish their resources to 158 follow them. The services themselves will move. "Evolutions" assumes 159 that the supporting infrastructure will evolve. This may take the form 160 of entirely new transport protocols or new versions of existing 161 protocols. Furthermore, services such as storage services may evolve; 162 it is even possible that within a human lifetime the Unix file system 163 model may no longer be in use! Clearly there will be evolution of and 164 improvement in supporting authentication and security mechanisms. These 165 are only examples. In general, we must assume that almost any piece of 166 the supporting infrastructure of URN resolution will evolve. In order 167 to deal with both the mobility and evolution assumptions that derive 169 URN Resolution Requirements Page 3 170 from the assumption of longevity, we must assume that users and their 171 applications can remain independent of these mutating details of the 172 supporting infrastructure. 174 The second and third assumptions are two forms of modularity, delegation 175 and isolation. The delegation assumption is that an entity may 176 partition and pass off some of its authority or responsibility. One of 177 those responsibilities is for assigning URNs; practically speaking, 178 there cannot be only a single authority for assigning URNs. We expect 179 that there will be a multi-tiered naming authority delegation. 180 Furthermore, it is difficult to imagine a non-partitioned and delegated 181 global UDS, meaning that hint discovery and resolution will be 182 partitioned and delegated. In some UDS schemes, the delegation of 183 naming authority will form a basis for delegating the management and 184 dispensing of location information. 186 The third assumption is independence or isolation of one authority from 187 another and, at least to some extent from its parent. Underlying much 188 of the thinking and discussion in the URI and URN working groups has 189 been the assumption that when a component delegates authority to another 190 component, the delegatee can operate in that domain independently of its 191 peers and within bounds specified by the delegation, independently of 192 the delegator. This isolation is critically important in order to allow 193 for independence of policy and mechanism. 195 There are a number of more specific assumptions that fall under this 196 rubric of isolation. First, we assume that the publisher of a resource 197 can choose resolution services, independently of choices made by others. 198 At any given time, the owner of a namespace may choose a particular URN 199 resolution service for that delegated namespace. Such a URN resolution 200 service may be outside the UDS service model, and just identified or 201 located by the UDS service. Second, it must be possible to make a 202 choice among UDS services, perhaps based on different underlying 203 internal architectures. The reason that this is an assumption is that 204 there must be an evolutionary path through a sequence of core UDS 205 services. Although at any given time there is likely to be only one or 206 a small set of such services, the number is likely to increase during a 207 transition period from one architecture to another. Thus, it must be 208 assumed that clients can make a choice among a probably very small set 209 of UDSs. Third, there must be independence in the choice about levels 210 and models of security and authenticity required. This choice may be 211 made by the owner of a naming subspace, in controlling who can modify 212 hints in that subspace. A naming authority may delegate this choice to 213 the owners of the resources named by the names it has assigned. There 214 may be limitations on this freedom of choice in order to allow other 215 participants to have the level of security and authenticity they 216 require, for example, in order to maintain the integrity of the UDS 217 infrastructure as a whole. Fourth, there is an assumption of 218 independence of choice of the rule of canonicalization of URNs within a 219 namespace, limited by any restrictions or constraints that may have been 220 set by its parent namespace. This is a choice held by naming 221 authorities over their own subnamespaces. Rules for canonicalization 222 will be discussed further in the framework section below. Thus, there 223 are assumptions of independence and isolation to allow for delegated, 224 independent authority in a variety of domains. 226 URN Resolution Requirements Page 4 227 The modularity assumptions of delegation and isolation imply 228 independence of decision and implementation, leading to a 229 decentralization that provides a certain degree of safety from denial of 230 service. Based on these these assumptions in conjunction with that of 231 longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737, 232 we can now turn to the requirements for a URN services delegation 233 service. 235 3. Requirements 237 The requirements applying to a URN-resolution-service discovery service 238 or UDS center around three important design goals: evolvability, 239 usability, and security and privacy. At its core the function of a UDS 240 is to provide hints for accessing a resource given a URN for it. These 241 hints may range in applicability from local to global, and from 242 short-lived to long-lived. They also may vary in their degree of 243 verifiable authenticity. While it may be neither feasible nor necessary 244 that initial implementations support every requirement, every 245 implementation must support evolution to systems that do support every 246 requirement. 248 It is also important to note that there are other requirements, not 249 applicable specifically to a UDS that must also be met. A whole URN 250 system will consist of namespaces, the resolution information for them, 251 and the mapping from names in the namespaces to resolution information 252 (or hints). URN schemes must meet the requirements of RFC 1737. 253 Resolution information, to the extent it is expressed as URLs must meet 254 the requirements of RFC 1736. But this does not tell the whole story. 255 Although the URN working group will identify several acceptable 256 namespaces and the rules binding them, such as how delegation occurs, 257 how it is expressed in the names, how and to what extent binding to hint 258 information will be constrained by the namespace, in the long run a 259 document will be needed to guide the evaluation criteria for acceptance 260 of new namespaces. These are not included in the list of requirements 261 below because they are not requirements for a UDS, but rather for naming 262 schemes themselves. 264 3.1 Evolution 266 One of the lessons of the Internet that we must incorporate into the 267 development of mechanisms for resolving URNs is that we must be prepared 268 for change. Such changes may happen slowly enough to be considered 269 evolutionary modifications of existing services or dramatically enough 270 to be considered revolutionary. They may permeate the Internet universe 271 bit by bit, living side by side with earlier services or they may take 272 the Internet by storm, causing an apparent complete transformation over 273 a short period of time. There are several directions in which we can 274 predict the need for evolution, even at this time, prior to the 275 deployment of any such service. At the very least, the community and 276 the mechanisms proposed should be prepared for these. 278 First, we expect there to be additions and changes to the mechanisms. 279 The community already understands that there must be a capacity for new 280 URN schemes. A URN scheme will define a set of URNs that meet the URN 281 requirements[RFC1737], but may have further constraints on the internal 283 URN Resolution Requirements Page 5 284 structure of the URN. The requirements document would allow for an 285 overall plan in which URN schemes are free to specify parts of the URN 286 that are left opaque in the larger picture. In fact, a URN scheme may 287 choose to make public the algorithms for any such "opaque" part of the 288 URN. For example, although it may be unnecessary to know the structure 289 of an ISBN, the algorithm for understanding the structure of an ISBN has 290 been made public. Other schemes may either choose not to make their 291 algorithms public, or choose a scheme in which knowledge of the scheme 292 does not provide any significant semantics to the user. In any case, we 293 must be prepared for a growing number of URN schemes. 295 Often in conjunction with a new URN scheme, but possibly independently 296 of any particular URN scheme, new resolution services may evolve. For 297 example, one can imagine a specialized resolution service based on the 298 particular structure of ISBNs that improves the efficiency of finding 299 documents given their ISBNs. Alternatively, one can also imagine a 300 general purpose resolution service that trades performance for 301 generality; although it exhibits only average performance resolving 302 ISBNs, it makes up for this weakness by understanding all existing URN 303 schemes, so that its clients can use the same service to resolve URNs 304 regardless of naming scheme. In this context, there will always be room 305 for improvement of services, through improved performance, better 306 adaptability to new URN schemes, or lower cost. In any case, new models 307 for URN resolution will evolve and we must be prepared to allow for 308 their participation in the overall resolution of URNs. 310 If we begin with one overall plan for URN resolution, into which the 311 enhancements described above may fit, we must also be prepared for an 312 evolution in the authentication schemes that will be considered either 313 useful or necessary in the future. There is no single globally accepted 314 authentication scheme, and there may never be one. Even if one does 315 exist at some point in time, there will always be threats to it, and so 316 we must always be prepared to move on to newer and better schemes, as 317 the old ones become too easily spoofed or guessed. 319 Lastly, in terms of mechanism, although we may develop and deploy a 320 single UDS scheme initially, we must be prepared for that top level 321 model to evolve. Thus, if the UDS model supports an apparently 322 centralized (from a policy standpoint) scheme for inserting and 323 modifying authoritative information, over time we must be prepared to 324 evolve to a different model, perhaps one that has a more distributed 325 model of authority and authenticity. If the model has no core but 326 rather a cascaded partial discovery of information, we may find that 327 this becomes unmanageable with an increase in scaling. Whatever the 328 core of the model, we must be prepared for it to evolve with changes in 329 scaling, performance, and policy constraints such as security and cost. 331 Second, in addition to the evolution of resolution mechanisms, we expect 332 that the community will follow an evolutionary path towards the 333 separation of semantics from identification. The URN requirements 334 document suggested this path as well, and there has been general 335 agreement in much of the community that such a separation is desirable. 336 This is a problem that the public at large has generally not understood. 337 Today we see the problem most clearly with the use of URLs for 338 identification. When a web page moves, its URL becomes invalid. 340 URN Resolution Requirements Page 6 341 Suppose such a URL is embedded in some page, stored in long term 342 storage. There are three possible outcomes to this scenario. One 343 possibility is that the client is left high and dry with some message 344 saying that the page cannot be found. Alternatively, a "forwarding 345 pointer" may be left behind, in the form of an explicit page requesting 346 the client to click on a new URL. Although this will allow the client 347 to find the intended page, the broken link cannot be fixed because the 348 URL is embedded in a file outside of the client's control. A third 349 alternative is that the target server supplies an HTTP redirect so that 350 the new page is provided for the client automatically. In this case, 351 the client may not even realize that the URL is no longer correct. The 352 real problem with both of these latter two situations is that they only 353 work as long as the forwarding pointer can be found at the old URL. 354 Semantics, in this case location information, was embedded in the 355 identifier, and the resolution system was designed to depend on the 356 semantics being correct. There are few cases in which we can expect 357 semantics of any sort to remain valid for a long time, but in many cases 358 references need to have long lifespans. Most documents are only useful 359 while their references still function. 361 We expect the evolution to separation of semantics from identification 362 to move along at least three paths. The first will be to develop 363 temporary aliases to capture the semantics currently embedded in 364 identifiers. This will require additional translation, but it will 365 allow for the development of semantics-free URNs. Second, we expect 366 locally shared or private aliases to arise, again supported by a 367 translation mechanism and allowing for the long-term storage of global, 368 semantics-free URNs. Such an aliasing scheme may be used to permit 369 local aliases for named resources as well as to present these aliases to 370 users in lieu of the URNs themselves. Lastly, we expect there may be a 371 development of global aliases. These will be more user friendly "names" 372 that would be shared on a much larger scale, and might be defined in 373 some global registry. This may include trademarked names as well as 374 names in extremely common use. As with the other alias systems, a 375 facility for translation is needed. However, in this case, since the 376 system of aliases is of global scope, the translation facility will be 377 very slow if each time an alias is translated it needs to query a 378 centralized or even reasonably distributed global registry. In order to 379 achieve acceptable speeds, the translation facility will need to 380 maintain a local cache, possibly in cooperation with other nearby alias 381 caches. Clearly this is all postulation at present, but it is provided 382 here to demonstrate some of the scope of evolution for which we must be 383 prepared. 385 A third evolutionary requirement is even more mechanical than the 386 others. At any point in time, the community is likely to be supporting 387 a compromise position with respect to resolution. We will probably be 388 operating in a situation balanced between feasibility and the ideal, 389 perhaps with policy controls used to help stabilize the service. 390 Ideally, the service would be providing exactly what the customers 391 wanted and they in turn would not request more support than they need. 392 Since we will always be in a situation in which some service provision 393 resources will be in short supply, some form of policy controls will 394 always be necessary. For example, suppose hint entries are being 395 submitted in such volume that the hint servers are using up their excess 397 URN Resolution Requirements Page 7 398 capacity and need more disk space. An effective solution to this 399 problem would be a mechanism such as a pricing policy. This pricing 400 policy has the dual effect of both encouraging conservative use of 401 resources and collecting revenue for the improvement and maintenance of 402 the system. As technology changes and the balance of which resources 403 are in short supply changes, the mechanisms and policies for controlling 404 their use must evolve as well. 406 In summary, the requirements in the area of evolvability are: 408 * To support evolution of mechanisms, specifically for 409 a) a growing set of URN schemes; 410 b) new local URN resolution schemes; 411 c) new authentication schemes; 412 d) alternative UDS schemes active simultaneously; 413 * To support and encourage the evolution toward the separation of 414 global identification from short-lived, locally useful, or human 415 friendly semantics; 416 * To support the development and deployment of pricing models to 417 manage human behavior with respect to limited resources. 419 3.2 Usability and Feature Set Requirements 421 Usability can be evaluated from three distinct perspectives: those of a 422 publisher wishing to make a piece of information public, those of a 423 client requesting URN resolution, and those of the provider or manager 424 of resolution information. We will separately address the usability 425 requirements from each of these three perspectives. 427 It is worth noting that there are two additional sorts of participants 428 in the whole naming process, as discussed in the URN WG. They are the 429 naming authorities which choose and assign names, and the authors who 430 include URNs in their resources. These two are not relevant to the 431 design of a UDS and hence are not discussed further here. 433 3.2.1 The Publisher 435 The publisher must be able to make URNs known to potential customers. 436 From the perspective of a publisher, it is of primary importance that 437 URNs be correctly and efficiently resolvable by potential clients. 438 Publishers also stand to gain from long-lived URNs, since they increase 439 the chance that references continue to point to their published 440 resources. The publisher must also be able to choose easily among a 441 variety of potential services that might translate URNs to location 442 information. In order to allow for this mobility among resolution 443 services, the architecture for resolution services specified within the 444 IETF should not result in a scenario in which changing from one 445 resolution service to another is an expensive operation. 447 The publisher should be able to arrange for multiple access points to a 448 published resource. For this to be useful, resolution services should 449 be prepared to provide different resolution or hint information to 450 different clients, based on a variety of information including location 451 and the various access privileges the client might have. For example, 452 companies might arrange for locally replicated copies of popular 454 URN Resolution Requirements Page 8 455 resources, and would like to provide access to the local copies only for 456 their own employees. This is distinct from access control on the 457 resource as a whole, and may be applied differently to different copies. 459 The publisher should be able to provide both long and short term 460 information about accessing the resource. Long term information is 461 likely to be such information as the long term location of the resource 462 or the location or identity of a resolution service with which the 463 publisher has a long term relationship. One can imagine that the 464 arrangement with such a long term "authoritative" resolution service 465 might be a guarantee of reliability, resiliency to failure, and atomic 466 updates. Shorter term information is useful for short term changes in 467 services or to avoid short lived congestion or failure problems. For 468 example, if the actual repository of the resource is temporarily 469 inaccessible, the resource might be made available from another 470 repository. This short term information can be viewed as temporary 471 refinements of the longer term information, and as such should be more 472 easily and quickly made available, but may be less reliable. 474 Lastly, the publishers will be the source of much hint information that 475 will be stored and served by the manager of the infrastructure. Despite 476 the fact that many publishers will not understand the details of the UDS 477 mechanism, it must be easy and straightforward to install hint 478 information. The publisher must be able not only to express hints, but 479 also to verify that what is being served by the manager is correct. 480 Furthermore, to the extent that there are security constraints on hint 481 information, the publisher must be able to both express them and verify 482 compliance to them easily. 484 3.2.2 The Client 486 From the perspective of the client, simplicity and usability are 487 paramount. Of critical importance to serving clients effectively is 488 that there be an efficient protocol through which the client can acquire 489 hint information. Since resolving the name is only the first step on 490 the way to getting access to a resource, the amount of time spent on it 491 must be minimized. 493 Furthermore, it will be important to be able to build simple, standard 494 interfaces to the UDS so that both the client and applications on the 495 client's behalf can interpret hints and subsequently make informed 496 choices. The client, perhaps with the assistance of the application, 497 must be able to specify preferences and priorities and then apply them. 498 If the ordering of hints is only partial, the client may become directly 499 involved in the choice and interpretation of them and hence they must be 500 understandable to that client. On the other hand, in general it should 501 be possible to configure default preferences, with individual 502 preferences viewed as overriding any defaults. 504 From the client's perspective, although URNs will provide important 505 functionality, the client is most likely to interact directly only with 506 human friendly names (HFNs). As in direct human interaction (not 507 computer mediated), the sharing of names will be on a small,private, or 508 domain specific scale. HFNs will be the sorts of references and names 509 that are easy to remember, type, choose among, assign, etc. There will 511 URN Resolution Requirements Page 9 512 also need to be a number of mechanisms for mapping HFNs to URNs. Such 513 services as "yellow pages" or "search tools" fall into this category. 514 Although we are mentioning HFNs here, it is important to recognize that 515 HFNs and the mappings from HFNs to URNs is and must remain a separate 516 functionality from a UDS. Hence, although HFNs will be critical to 517 clients, they do not fall into the domain of this document. 519 3.2.3 The Management 521 Finally, we must address the usability concerns with respect to the 522 management of the hint infrastructure itself. What we are terming 523 "management" is a service that is distinct from publishing; it is the 524 core of a UDS. It involves the storage and provision of hints to the 525 clients, so that they can find published resources. It also provides 526 security to the extent that there is a commitment for provision of such 527 security; this is addressed below. 529 The management of hints must be as unobtrusive as possible. First, its 530 infrastructure (hint storage servers and distribution protocols) should 531 have as little impact as possible on other network activities. It must 532 be remembered that this is an auxiliary activity and must remain in the 533 background. 535 Second, in order to make hint management feasible, there will need to be 536 a system for economic incentives and disincentives. Recovering the cost 537 of running the system is only one reason for levying charges. The 538 introduction of payments often has a beneficial impact on social 539 behavior. It may be necessary to discourage certain forms of behavior 540 that when out of control have serious negative impact on the whole 541 community. At the same time, payment policies should encourage behavior 542 that benefits the community as a whole. Thus, for example, a small 543 one-time charge for authoritatively storing a hint will encourage 544 conservative use of hints. If we assume that there is a fixed cost for 545 managing a hint, then the broader its applicability across the URN 546 space, the more cost effective it is. That is, when one hint can serve 547 for a whole collection of URNs, there will be an incentive to submit one 548 general hint over a large number of more specific hints. Similar 549 policies can be instituted to discourage the frequent changing of hints. 550 In these ways and others, cost effective behavior can be encouraged. 552 Lastly, symmetric to issues of usability for publishers, it must also be 553 simple for the management to configure the mapping of URNs to hints. It 554 must be easy both to understand the configuration and to verify that 555 configuration is correct. With respect to management, this requirement 556 may have an impact not only on the information itself but also on how it 557 is partitioned among network servers that collaboratively provide the 558 management service or UDS. For example, it should be straightforward to 559 bring up a server and verify that the data it is managing is correct. 560 Since we are discussing a global and probably growing service, 561 encouraging volunteer participants requires that, as with the DNS, such 562 volunteers can feel confident about the service they are providing and 563 its benefit to both themselves and the rest of the community. 565 To summarize, the usability requirements fall into three areas based on 566 participation in hint management and discovery: 568 * The publisher 569 a) URN to hint resolution must be correct and efficient; 570 b) Publishers must be able to select among URN resolution 571 services to locate their resources; 572 c) Publishers must be able to arrange for multiple access points 573 for their location information; 574 d) Publishers must be able to provide for both long-lived and 575 short-lived hints; 576 e) It must be relatively easy for publishers to install and 577 observer their hint information and any security constraints 578 they need for their hints. 579 * The client 580 a) The interface to the UDS must be simple, effective, and 581 efficient; 582 b) The client and client applications must be able to understand 583 the information stored in and provided by the UDS, in order 584 to be able to make informed choices. 585 * The management 586 a) The management of hints must be as unobtrusive as possible, 587 avoiding using too many network resources; 588 b) A pricing scheme may be necessary to provide not only cost 589 recovery, but also social incentives and disincentives to 590 encourage certain sorts of behavior deemed necessary to meet 591 other requirements; 592 c) The configuration and verification of configuration of 593 individual UDS servers must be simple enough not to 594 discourage configuration and verification. 596 3.3 Security and Privacy Requirements 598 Although much of the information we are discussing in this document 599 might be considered "meta-information", there are some important 600 security and privacy concerns that must be addressed by a service 601 supporting that information. By first considering the sorts of attacks 602 that are of concern, we can then focus on the security and privacy 603 issues that are important. The reader will notice that integrity plays 604 less of a role here than might be expected. To the extent that servers 605 provide access control, the information they manage will have certain 606 integrity guarantees. Beyond that we must recognize that we are dealing 607 merely with hint information about the location of possibly interesting 608 resources. Therefore we believe that the benefit of providing integrity 609 guarantees beyond those provided by the servers themselves does not 610 outweigh the cost. 612 Because the majority of the activity will be the distribution of hint 613 information, the threats of concern are those affecting the maintenance 614 of correct information to distribute and the availability of the sources 615 of information. The first approach to URN resolution is to discover 616 local hints. By being local, they will be as widely distributed as 617 possible. The drawback of such wide distribution is the inability to 618 update them; therefore, they will become out of date with time. An 619 alternative or backup mechanism would concentrate hint information in 620 servers, thus requiring that update information only be distributed to 621 these servers. Hence the vulnerable points are the sources of the 622 information and the distribution network among them. If one assumes 623 that there will be principals of some sort that are responsible for the 624 information about each URN entry in the URN resolution service, then one 625 major threat is an attacker that masquerades as a valid principal and 626 inserts incorrect information into the service. A second threat vector 627 results from the fact that the service itself will be implemented by a 628 set of servers that collaborate and share the hint information critical 629 to their activities. By masquerading as a valid server in this pool, an 630 attacker can both provide incorrect information to clients and provide 631 incorrect information to other servers, which those servers will then 632 distribute. A third threat is that if the resolution service is too 633 centralized, service can be denied by a variety of network attacks 634 ranging from flooding the service with queries to causing various 635 network problems that will reduce access to the service. The more 636 centralized a service is the more vulnerable is the community that 637 trusts it not to be compromised. We can turn each of these into a 638 security goal. 640 * ACCESS CONTROL ON HINTS: There needs to be an authoritative version of 641 each hint, and it must support change control limited only to those 642 principals with the right to modify it. The choice of who those 643 principals are or whether they are unlimited must be made by the 644 publisher of a hint. 646 * SERVER AUTHENTICITY: Servers and clients must be able to learn the 647 identity of the servers with which they communicate. This will be a 648 matter of degree and it is possible that there will be more 649 trustworthy, but less accessible servers, supported by a larger 650 cluster of less authenticatable servers that are more widely 651 available. In the worst case, if the client receives what appears to 652 be invalid information, the client should assume that the hint may be 653 inaccurate and confirmation of the data should be sought from more 654 reliable but less accessible data. 656 * SERVER DISTRIBUTION: Broad availability will provide resistance to 657 denial of service. It is only to the extent that the services are 658 available that they provide any degree of trustworthiness. In 659 addition, the distribution of services will reduce to vulnerability 660 of the whole community, by reducing the trust put in any single 661 server. This must be mitigated by the fact that to the extent trust 662 is based on a linked set of servers, if any one fails, the whole 663 chain of trust fails; the more elements there are in such a chain, 664 the more vulnerable it may become. 666 _Ensuring_ privacy for clients and publishers is in some respects 667 essentially impossible. Fortunately, assuring a reasonable degree of 668 privacy for those who want it is possible. The privacy of clients is 669 primarily threatened by packet sniffers and servers that log requests. 670 A server or a packet sniffer can without much difficulty record the 671 contents of queries as they pass by and compile the information into a 672 relation between URNs and clients. This can be combatted by anonymizing 673 queries through a trusted, fairly local gateway, although it involves an 674 extra step and another potential bottleneck. The additional step can be 675 mitigated by caching responses in the gateway, thus often avoiding the 676 need to forward requests beyond it. A second alternative is to send 677 only partial queries. As will be discussed further in the framework 678 section, there may be two reasons for transformation of a URN, first to 679 canonicalize it and second to extract the identity of another server to 680 which to send a further request. This second alternative of sending 681 partial queries would be achieved by also extracting some partial URN to 682 further resolve at each stage. This would not anonymize the queries, 683 but might make them more difficult to chain together into a complete 684 story for logging. 686 On the other hand, to the degree that the search process is distributed, 687 packet sniffing at a single point is less likely to reveal data about a 688 specific person, and is hence less threatening to privacy. Furthermore, 689 if clients have flexibility in terms of the specific services they 690 choose to use, they can regularly switch services in the hopes of 691 foiling a packet sniffer watching their usual access point. 693 The privacy of publishers is much easier to safeguard. Since they are 694 trying to publish something, in some situations privacy is probably not 695 desired. However, publishers do have information that they might like 696 to keep private: information about who their clients are, and 697 information about what names exist in their namespace. The information 698 about who their clients are may be difficult to collect depending on the 699 implementation of the resolution system. For example, if the resolution 700 information relating to a given publisher is widely replicated, the hits 701 to _each_ replicated copy will need to be recorded. Of course, 702 determining if a specific client is requesting a given name can be 703 approached from the other direction, by watching the client as we saw 704 above. 706 The other privacy issue for publishers has to do with access control 707 over URN resolution. This issue is dependent on the implementation of 708 the publisher's authoritative URN resolution server. URN resolution 709 servers can be designed to require proof of identity in order to be 710 issued resolution information; if the client does not have permission to 711 access the URN requested, the service denies that such a URN exists. An 712 encrypted protocol can also be used so that both the request and the 713 response are obscured. Encryption is possible in this case because the 714 identity of the final recipient is known (i.e. the URN server). 716 In summary, security and privacy requirements can be identified as some 717 degree of protection from threats: 719 * It must be possible to create authoritative versions of a hint 720 with access to modification privileges controlled; 721 * It must be possible to determine the identity of servers or avoid 722 contact with unauthenticated servers; 723 * Broad availability of servers will reduce the thread to denial 724 of service; 725 * Client privacy is threatened by packet sniffing and server 726 logging. It is desirable to reduce these threats as much as 727 possible; 728 * It should be feasible for publishers to keep private certain 729 information such as an overall picture of the resources they are 730 publishing and the identity of their clients; 731 * Publishers should be able to restrict access to the resolution of 732 the URNs for the resources they publish, if they wish. 734 4. The Framework 736 With these assumptions and requirements in mind, one can conclude with a 737 general framework within which UDS designs will fall. As stated 738 earlier, although this framework is put forth as a suggested guide for 739 UDS designers, compliance with it will in no way guarantee compliance 740 with the requirements. Such an evaluation must be performed separately. 741 It is also understood that there may be UDS services that do not meet 742 the requirements in clearly identified ways. This may be true 743 especially with early plans and experiments. For example, although a 744 careful threat analysis may have been done to understand security 745 requirements, not all those security requirements may be addressed, in 746 order to use existing facilities to allow for early deployment for 747 experimentation purposes. All such lack of compliance should be clearly 748 documented. 750 The design of the framework is based on a simple assumption about the 751 syntax of a URN. This assumed syntax is: 753 URN:: 755 where URN: is a prefix on all URNs, NID is the namespace identifier, and 756 NSS is the namespace specific string. The prefix identifies each URN as 757 such. The NID determines the general syntax for all URNs within its 758 namespace. The NSS is probably partitioned into a set of delegated and 759 subdelegated namespaces, and this is probably reflected in further 760 syntax specifications. In the more complex environments, each delegated 761 namespace will be permitted to choose the syntax of the variable part of 762 the namespace that has been delegated to it. In simpler namespaces, the 763 syntax will be restricted completely by the parent namespace. For 764 example, although the DNS does not meet all the requirements for URNs, 765 it has a completely restricted syntax, such that any further structuring 766 must be done only by adding further refinements to the left, maintaining 767 the high order to low order, right to left structure. A delegated 768 syntax might be one in which a host is named by the DNS, but to the 769 right of that and separated by an "@" is a string whose internal 770 ordering is defined by the file system on the host, which may be defined 771 high order to low order, left to right. Of course, much more complex 772 and nested syntaxes should be possible, especially given the need to 773 grandfather namespaces. In order to resolve URNs, rules will be needed 774 for two reasons. One is simply to canonicalize those namespaces that do 775 not fall into a straightforward (probably right to left or left to 776 right) ordering of the components of a URN, as determined by the 777 delegated naming authorities involved. It is also possible that rules 778 will be needed in order to derive from URNs the names of UDS servers to 779 be used in stages. 781 The NID defines a top level syntax. This syntax will determine whether 782 the NID alone or in conjunction with some extraction from the NSS (for 783 the top level naming authority name) to identify the first level server 784 to be contacted. Each stage of the lookup either a new rule for 785 generating the strings used in yet another lookup (the strings being the 786 identify of another UDS server and possibly a string to be resolved if 787 it is different than the original URN) or a reference outside the UDS to 788 a private URN resolution service, sidestepping any furthere use of the 789 UDS scheme. Figure 1 depicts this process. 791 URN: 792 | 793 | 794 | 795 | 796 v 797 +-------------------+ 798 |Global NID registry| 799 +-------------------+ 800 | 801 | 802 | 803 (return rule or URN resolution service reference) 804 | 805 +----------------------------------+ 806 | | 807 +->(apply rule to determine UDS server) | 808 | | | 809 | | | 810 | | | 811 | +----------+ | 812 | |UDS server| +-----------------+ 813 | +----------+ | 814 | | | v 815 | | | (set of choices) 816 | | +----+----------(...)--------+ 817 | (rule) | | 818 | | | | 819 | | | | 820 +------+ | | 821 v v 822 +----------+ +----------+ 823 |private | |private | 824 |URN | |URN | 825 |resolution| |resolution| 826 |service | |service | 827 +----------+ +----------+ 829 Figure 1: A UDS framework 831 There are several points worth noting about the UDS framework. First, 832 it leaves open the determination of the protocols and data organization, 833 distribution and replication needed to support a particular UDS scheme. 834 Second, it leaves open the location of the computations engendered by 835 the rules. Third, it leaves open the possibility that partitioning 836 (distribution) of the UDS database need not be on the same boundaries as 837 the name delegation. This may seem radical to some, but if the 838 information is stored in balanced B-trees for example, the partitioning 839 may not be along those naming authority delegation boundaries. Lastly, 840 it leaves open access to the Global NID Registry. Is this distributed 841 to every client, or managed in widely distributed servers? One concept 842 that has not been addressed in Figure 1 is that there may be more than 843 one UDS available at any given time, in order to allow for evolution to 844 new schemes. Thus, the picture should probably look more like Figure 2. 846 URN:: 847 | 848 | 849 +-----------+-------(...)-------+ 850 | | 851 | | 852 | | 853 v v 854 +---------------------+ +---------------------+ 855 |Global NID registry 1| |Global NID registry N| 856 +---------------------+ +---------------------+ 857 . . 858 . . 859 . . 861 Figure 2: More than one co-existing UDS scheme 863 If we are to support more than one co-existing UDS scheme, there will 864 need to be coordination between them with respect to storage and 865 propagation of information and modifications. The issue is that 866 generally it should be assumed that all information should be available 867 through any operational UDS scheme. One cannot expect potential 868 publishers to submit updates to N UDS schemes. Hence there will need to 869 be a straightforward mapping of information from one to the other of 870 these schemes. It is possible that that transformation will only go in 871 one direction, because a newer UDS service is replacing an older one, 872 which is not kept up to date, in order to encourage transfer to the 873 newer one. Thus, at some point, updates may be made only to the newer 874 one and not be made available to the older one. Such a situation should 875 probably be avoided, if possible. 877 This framework is presented in order to suggest to UDS scheme designers 878 a direction in which to start designing. It is obvious to the reader 879 that adherence to this framework will in no way guarantee compliance 880 with the requirements or even assumption described in Sections 2 and 3. 881 These must be reviewed independently as part of the design process. 882 There is no single correct design that will meet these requirements. 883 Furthermore, it is assumed that preliminary proposals may not meet all 884 the requirements, but should be expected to itemized and justify any 885 lack of compliance. 887 5. References 889 [RFC1736] Kunze, J., "Functional Recommendations for Internet Resource 890 Locators", RFC 1736, February, 1995. 892 [RFC1737] Sollins, K. and Masinter, L., "Functional Requirements for 893 Uniform Resource Names", RFC 1738, December, 1994. 895 [RFC1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform 896 Resource Locators (URL)", RFC 1738, December, 1994. 898 6. Contact information: 900 Karen Sollins 901 MIT Laboratory for Computer Science 902 545 Technology Sq. 903 Cambridge, MA 02139 905 Tel: +1 617 253 6006 906 Email: sollins@lcs.mit.edu 908 This InternetDraft expires on May 26, 1997.