idnits 2.17.1 draft-ietf-urn-req-frame-01.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-16) 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 2 longer pages, the longest (page 1) being 60 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 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 (March 28, 1997) is 9881 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) == Missing Reference: 'R1' is mentioned on line 281, but not defined == Missing Reference: 'R2' is mentioned on line 289, but not defined == Missing Reference: 'R3' is mentioned on line 291, but not defined == Missing Reference: 'R4' is mentioned on line 424, but not defined == Missing Reference: 'R5' is mentioned on line 426, but not defined == Missing Reference: 'R6' is mentioned on line 428, but not defined == Missing Reference: 'R7' is mentioned on line 430, but not defined == Missing Reference: 'R8' is mentioned on line 432, but not defined == Missing Reference: 'R9' is mentioned on line 436, but not defined == Missing Reference: 'R10' is mentioned on line 438, but not defined == Missing Reference: 'R11' is mentioned on line 442, but not defined == Missing Reference: 'R12' is mentioned on line 444, but not defined == Missing Reference: 'R13' is mentioned on line 447, but not defined == Missing Reference: 'R14' is mentioned on line 615, but not defined == Missing Reference: 'R15' is mentioned on line 617, but not defined == Missing Reference: 'R16' is mentioned on line 619, but not defined == Missing Reference: 'R17' is mentioned on line 624, but not defined == Missing Reference: 'R18' is mentioned on line 627, but not defined == Missing Reference: 'R19' is mentioned on line 630, but not defined == Unused Reference: 'RFCXXX' is defined on line 981, but no explicit reference was found in the text ** 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) == Outdated reference: A later version (-05) exists of draft-ietf-urn-syntax-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'VK83' Summary: 17 errors (**), 0 flaws (~~), 23 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Karen R. Sollins 3 draft-ietf-urn-req-frame-01.txt MIT/LCS 4 Expires September 28, 1997 March 28, 1997 6 Requirements and a Framework for URN Resolution Systems 8 Status of this draft 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its 11 areas, and its working groups. Note that other groups may also 12 distribute working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet- 17 Drafts as reference material or to cite them other than as 18 ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check 21 the ``1id-abstracts.txt'' listing contained in the Internet- 22 Drafts Shadow Directories on ftp.is.co.za (Africa), 23 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 24 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 26 Abstract: 28 This document addresses the issues of the discovery of local URN 29 resolver services that in turn will directly translate URNs into 30 URLs and URCs. The document falls into three major parts, the 31 assumptions underlying the work, the requirements in order to be a 32 viable Resolver Discovery Service or RDS to help in finding URN 33 resolvers, and a framework for designing RDSs. The requirements fall 34 into three major areas: evolvability, usability, and security and 35 privacy. An RDS that is compliant with the framework will not 36 necessarily be compliant with the requirements. Compliance with the 37 requirements will need to be 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 resolvers. This is a 44 component of the realization of an information infrastructure. In the 45 case of this work, that infrastructure is to be available, "in the 46 Internet" or globally, and hence the solutions to the problems we are 47 addressing must globally scalable. In this work, we are focussing 48 specifically on naming of resources and resolution of those names to 49 the exclusion of other problems such as typing, resource access and 50 availability, security of the resources, etc. Those are all important 51 problems, but not part of this effort. 53 The Uniform Resource Identifier Working Group defined a naming 54 architecture, as demonstrated in a series of three RFCs 1736[RFC1736], 56 - 1 - 57 1737{RFC1737}, and 1738[RFC1738]. Although several further documents 58 are needed to complete the description of that architecture, it 59 incorporates three core functions often associated with "naming": 60 identification, location, and mnemonics or semantics. By location, we 61 mean full-qualified Domain Names or IP addresses. Names may provide 62 the ability to distinguish one resource from another, by 63 distinguishing their "names". Names may help to provide access to a 64 resource by including "location" information. Lastly, names may have 65 other semantic or mnemonic information that either helps human users 66 remember or figure out the names, or include other semantic 67 information about the resource being named. The URI working group 68 concluded that there was need for persistent, globally unique 69 identifiers, distinct from location or other semantic information; 70 these "names" provide identity, in that if two of them are "the same" 71 (under some simple rule of canonicalization), they identify the same 72 resource. Furthermore, the group decided that these "names" were 73 generally to be for machine, rather than human consumption. One can 74 imagine a variety human-friendly naming (HFN) schemes supporting 75 different suites of applications and user communities. These will 76 need to provide mappings to URNs in tighter or looser couplings, 77 depending on the namespace. It is these that will be mnemonic, 78 content-full, and perhaps mutable, to track changes in use and 79 semantics. They may provide nicknaming and other aliasing, relative 80 or short names, context sensitive names, descriptive names, etc. The 81 URI naming architecture as described in the introductions to RFCs 1736 82 and 1737 lays out three sorts of components to the naming 83 architecture: identifiers called Uniform Resource Names (URNs), 84 locators called Uniform Resource Locators (URLs) and semantic 85 meta-information called Uniform Resource Characteristics (URCs). This 86 document focusses on part of the problem of the translation from URN 87 to URL and/or URC. 89 Within the URI community there has been a concept used frequently that 90 for lack of a better term we will call a _hint_. A hint is something 91 that helps in the resolution of a URN; we map URNs to hints as an 92 interim stage in accessing a resource. A hint may also have 93 meta-information associated with it, such as an expiration_time or 94 certification of authenticity. We expect that these will stay with a 95 hint rather than being managed elsewhere. We will assume in all 96 further discussion of hints that they include any necessary 97 meta-information as well as the hint information itself. Examples of 98 hints are: 1) the name of a resolver service that may further resolve 99 the URN, 2) the address of such a service, 3) a location at which the 100 resource was previously found. The defining feature of hints is that 101 they are only hints; they may be out of date, temporarily invalid, or 102 only applicable within a specific locality. They do not provide a 103 guarantee of access, but they probably will help in the resolution 104 process. We must assume that most resolutions of URNs will be 105 provided by the use of locally stored hints, because maintaining a 106 database of globally available, completely up-to-date location 107 information is infeasible for performance reasons. There are a number 108 of circumstances in which one can imagine that hints become invalid, 109 either because a resource has moved or because a different URN 110 resolver service has taken over the responsibility for resolution of 111 the URN. Hints may be found in a variety of places. It is generally 112 assumed that a well engineered system will maintain a set of hints for 114 - 2 - 115 each URN at each location where that URN is found. In addition, for 116 those situations in which those hints found locally fail, a 117 well-engineered system will provide a fall-back mechanism for 118 discovering further hints. It is this fall-back mechanism, an RDS, 119 that is being addressed in this document. As with all hints, there 120 can never be a guarantee that access to a resource will be available 121 to all clients, even if the resource is accessible to some. However, 122 an RDS is expected to work with reasonably high reliability, and, 123 hence, may result in increased response time. 125 The remainder of this document falls into three sections. The first 126 identifies several sets of assumptions underlying this work. The next 127 lays out the requirements for a Resolver Discovery Service. This 128 section is probably the most critical of the document, because it is 129 this that provides the metric for whether or not a proposed scheme for 130 a RDS is adequate or not. For the reader short on time, each of the 131 three major subsections of the requirements section begins with a 132 summary list of the requirements identified in that section. The 133 final section of the document lays out a framework for such RDSs. The 134 purpose of this last section is to bound the search space for RDS 135 schemes. One must be careful not to assume that because an RDS scheme 136 fits within the framework that it necessarily meets the requirements. 137 As will be discussed further in this last section, designing within 138 the framework does not guarantee compliance, so compliance evaluation 139 must also be part of the process of evaluation of a scheme. 141 2. Assumptions 143 Based on previous internet drafts and discussion in both the URN BOFs 144 and on the URN WG mailing list, three major areas of assumptions are 145 apparent: longevity, delegation, and independence. Each will be 146 discussed separately. 148 The URN requirements state that a URN is to be a "persistent 149 identifier". It is probably the case that nothing will last forever, 150 but in the time frame of resources, users of those resources, and the 151 systems to support the resources, the identifier should be considered to 152 be persistent or have a longer lifetime than those other entities. 153 There are two assumptions that are implied by longevity of URNs: 154 mobility and evolution. "Mobility" assumes that everything will move 155 over the life of a URN. For example, resources will move from one 156 machine to another, because individual machines have a much shorter 157 lifetime than resources, generally measured in a number of years less 158 than a decade. Owners of resources may move and wish their resources to 159 follow them. The services themselves will move. "Evolution" assumes 160 that the supporting infrastructure will evolve. This may take the form 161 of entirely new transport protocols or new versions of existing 162 protocols. Furthermore, services such as storage services may evolve; 163 it is even possible that within a human lifetime the Unix file system 164 model may no longer be in use! Clearly there will be evolution of and 165 improvement in supporting authentication and security mechanisms. These 166 are only examples. In general, we must assume that almost any piece of 167 the supporting infrastructure of URN resolution will evolve. In order 168 to deal with both the mobility and evolution assumptions that derive 169 from the assumption of longevity, we must assume that users and their 171 - 3 - 172 applications can remain independent of these mutating details of the 173 supporting infrastructure. 175 The second and third assumptions are two forms of modularity: delegation 176 and isolation. The delegation assumption is that an entity may 177 partition and pass off some of its authority or responsibility. One of 178 those responsibilities is for assigning URNs; practically speaking, 179 there cannot be only a single authority for assigning URNs. We expect 180 that there will be a multi-tiered naming authority delegation. 181 Furthermore, it is difficult to imagine a non-partitioned and delegated 182 global RDS, meaning that hint discovery and resolution will be 183 partitioned and delegated. In some RDS schemes, the delegation of 184 naming authority will form a basis for delegating the management and 185 dispensing of location information. 187 The third assumption is independence or isolation of one authority from 188 another and, at least to some extent from its parent. Underlying much 189 of the thinking and discussion in the URI and URN working groups has 190 been the assumption that when a component delegates authority to another 191 component, the delegatee can operate in that domain independently of its 192 peers and within bounds specified by the delegation, independently of 193 the delegator. This isolation is critically important in order to allow 194 for independence of policy and mechanism. 196 There are a number of more specific assumptions that fall under this 197 rubric of isolation. First, we assume that the publisher of a resource 198 can choose resolver services, independently of choices made by others. 199 At any given time, the owner of a namespace may choose a particular URN 200 resolver service for that delegated namespace. Such a URN resolver 201 service may be outside the RDS service model, and just identified or 202 located by the RDS service. Second, it must be possible to make a 203 choice among RDS services, perhaps based on different underlying 204 internal architectures. The reason that this is an assumption is that 205 there must be an evolutionary path through a sequence of core RDS 206 services. Although at any given time there is likely to be only one or 207 a small set of such services, the number is likely to increase during a 208 transition period from one architecture to another. Thus, it must be 209 assumed that clients can make a choice among a probably very small set 210 of RDSs. Third, there must be independence in the choice about levels 211 and models of security and authenticity required. This choice may be 212 made by the owner of a naming subspace, in controlling who can modify 213 hints in that subspace. A naming authority may delegate this choice to 214 the owners of the resources named by the names it has assigned. There 215 may be limitations on this freedom of choice in order to allow other 216 participants to have the level of security and authenticity they 217 require, for example, in order to maintain the integrity of the RDS 218 infrastructure as a whole. Fourth, there is an assumption of 219 independence of choice of the rule of canonicalization of URNs within a 220 namespace, limited by any restrictions or constraints that may have been 221 set by its parent namespace. This is a choice held by naming 222 authorities over their own subnamespaces. Rules for canonicalization 223 will be discussed further in the framework section below. Thus, there 224 are assumptions of independence and isolation to allow for delegated, 225 independent authority in a variety of domains. 227 - 4 - 228 The modularity assumptions of delegation and isolation imply 229 independence of decision and implementation, leading to a 230 decentralization that provides a certain degree of safety from denial of 231 service. Based on these these assumptions in conjunction with that of 232 longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737, 233 we can now turn to the requirements for a Resolver Discovery Service. 235 3. Requirements 237 The requirements applying to a Resolver Discovery Service or RDS 238 center around three important design goals: evolvability, usability, 239 and security and privacy. At its core the function of an RDS is to 240 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 244 necessary that initial implementations support every requirement, 245 every implementation must support evolution to systems that do support 246 every requirement. 248 It is important to note that there are other requirements, not 249 applicable specifically to an RDS 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 an RDS, but rather for naming 262 schemes themselves. 264 Each section below begins with a summary of the points made and discussed 265 in the following discussion. It is worth noting here that there is 266 some degree of overlap in the areas of requirements, such as in 267 allowing for the evolution of security mechanisms, etc. Issues may 268 appear in more than one requirement. It is also important to 269 recognize that conformance with the requirements may often be 270 subjective. Most of these requirements are not quantifiable and hence 271 conformance is a judgment call and a matter of degree. Lastly, the 272 reader may find that some of the requirements are those of general 273 applicability to distributed systems and some are specific to URN 274 resolution. Those of general applicability are included for 275 completeness and are not distinguished as such. 277 3.1 Evolution 279 The requirements in the area of evolvability are: 281 [R1] To support evolution of mechanisms, specifically for 282 {R1.1] a growing set of URN schemes; 284 - 5 - 286 [R1.2] new kinds local URN resolver services; 287 [R1.3] new authentication schemes; 288 [R1.4] alternative RDS schemes active simultaneously; 289 [R2] To support the separation of global identification from 290 location information. 291 [R3] To allow for the support the development and deployment of 292 administrative control mechanisms to manage human behavior 293 with respect to limited resources. 295 One of the lessons of the Internet that we must incorporate into the 296 development of mechanisms for resolving URNs is that we must be prepared 297 for change. Such changes may happen slowly enough to be considered 298 evolutionary modifications of existing services or dramatically enough 299 to be considered revolutionary. They may permeate the Internet universe 300 bit by bit, living side by side with earlier services or they may take 301 the Internet by storm, causing an apparent complete transformation over 302 a short period of time. There are several directions in which we can 303 predict the need for evolution, even at this time, prior to the 304 deployment of any such service. At the very least, the community and 305 the mechanisms proposed should be prepared for these. 307 First, we expect there to be additions and changes to the mechanisms. 308 The community already understands that there must be a capacity for new 309 URN schemes. A URN scheme will define a set of URNs that meet the URN 310 requirements[RFC1737], but may have further constraints on the internal 311 structure of the URN. The requirements document would allow for an 312 overall plan in which URN schemes are free to specify parts of the URN 313 that are left opaque in the larger picture. In fact, a URN scheme may 314 choose to make public the algorithms for any such "opaque" part of the 315 URN. For example, although it may be unnecessary to know the structure 316 of an ISBN, the algorithm for understanding the structure of an ISBN has 317 been made public. Other schemes may either choose not to make their 318 algorithms public, or choose a scheme in which knowledge of the scheme 319 does not provide any significant semantics to the user. In any case, we 320 must be prepared for a growing number of URN schemes. 322 Often in conjunction with a new URN scheme, but possibly independently 323 of any particular URN scheme, new kinds of resolver services may 324 evolve. For example, one can imagine a specialized resolver service 325 based on the particular structure of ISBNs that improves the 326 efficiency of finding documents given their ISBNs. Alternatively, one 327 can also imagine a general purpose resolver service that trades 328 performance for generality; although it exhibits only average 329 performance resolving ISBNs, it makes up for this weakness by 330 understanding all existing URN schemes, so that its clients can use 331 the same service to resolve URNs regardless of naming scheme. In this 332 context, there will always be room for improvement of services, 333 through improved performance, better adaptability to new URN schemes, 334 or lower cost. In any case, new models for URN resolution will evolve 335 and we must be prepared to allow for their participation in the 336 overall resolution of URNs. 338 If we begin with one overall plan for URN resolution, into which the 339 enhancements described above may fit, we must also be prepared for an 341 - 6 - 342 evolution in the authentication schemes that will be considered either 343 useful or necessary in the future. There is no single globally accepted 344 authentication scheme, and there may never be one. Even if one does 345 exist at some point in time, there will always be threats to it, and so 346 we must always be prepared to move on to newer and better schemes, as 347 the old ones become too easily spoofed or guessed. 349 Lastly, in terms of mechanism, although we may develop and deploy a 350 single RDS scheme initially, we must be prepared for that top level 351 model to evolve. Thus, if the RDS model supports an apparently 352 centralized (from a policy standpoint) scheme for inserting and 353 modifying authoritative information, over time we must be prepared to 354 evolve to a different model, perhaps one that has a more distributed 355 model of authority and authenticity. If the model has no core but 356 rather a cascaded partial discovery of information, we may find that 357 this becomes unmanageable with an increase in scaling. Whatever the 358 core of the model, we must be prepared for it to evolve with changes in 359 scaling, performance, and policy constraints such as security and cost. 361 Second, in addition to the evolution of resolution mechanisms, we 362 expect that the community will follow an evolutionary path towards the 363 separation of location information from identification. The URN 364 requirements document suggested this path as well, and there has been 365 general agreement in much of the community that such a separation is 366 desirable. This is a problem that the public at large has generally 367 not understood. Today we see the problem most clearly with the use of 368 URLs for identification. When a web page moves, its URL becomes 369 invalid. Suppose such a URL is embedded in some page, stored in long 370 term storage. There are three possible outcomes to this scenario. 371 One possibility is that the client is left high and dry with some 372 message saying that the page cannot be found. Alternatively, a 373 "forwarding pointer" may be left behind, in the form of an explicit 374 page requesting the client to click on a new URL. Although this will 375 allow the client to find the intended page, the broken link cannot be 376 fixed because the URL is embedded in a file outside of the client's 377 control. A third alternative is that the target server supplies an 378 HTTP redirect so that the new page is provided for the client 379 automatically. In this case, the client may not even realize that the 380 URL is no longer correct. The real problem with both of these latter 381 two situations is that they only work as long as the forwarding 382 pointer can be found at the old URL. Location information, was 383 embedded in the identifier, and the resolution system was designed to 384 depend on that location information being correct. There are few 385 cases in which we can expect such information to remain valid for a 386 long time, but in many cases references need to have long lifespans. 387 Most documents are only useful while their references still function. 388 To the extent that an RDS scheme supports the separation of global 389 identification from location information it will be encouraging the 390 longer utility of the identities. 392 A third evolutionary requirement is even more mechanical than the 393 others. At any point in time, the community is likely to be 394 supporting a compromise position with respect to resolution. We will 395 probably be operating in a situation balanced between feasibility and 396 the ideal, perhaps with policy controls used to help stabilize the 398 - 7 - 399 service. Ideally, the service would be providing exactly what the 400 customers wanted and they in turn would not request more support than 401 they need. Since we will always be in a situation in which some 402 service provision resources will be in short supply, some form of 403 policy controls will always be necessary. Some policy controls may be 404 realized as mechanisms within the servers or in the details of 405 protocols, while others may only be realized externally to the system. 406 For example, suppose hint entries are being submitted in such volume 407 that the hint servers are using up their excess capacity and need more 408 disk space. An effective solution to this problem would be a 409 mechanism such as a pricing policy. This pricing policy has the dual 410 effect of both encouraging conservative use of resources and 411 collecting revenue for the improvement and maintenance of the system. 412 We can also imagine administrative policy controls with the force of 413 laws or other social pressures behind them, but with no technical 414 mechanism enforcing or enabling them. As technology changes and the 415 balance of which resources are in short supply changes, the mechanisms 416 and policies for controlling their use must evolve as well. 418 3.2 Usability and Feature Set Requirements 420 To summarize, the usability requirements fall into three areas based on 421 participation in hint management and discovery: 423 * The publisher 424 [R4] URN to hint resolution must be correct and efficient with 425 very high probability; 426 [R5] Publishers must be able to select and move among URN 427 resolver services to locate their resources; 428 [R6] Publishers should be able to arrange for multiple access 429 points for their location information; 430 [R7] Publishers must be able to provide for both long-lived and 431 short-lived hints; 432 [R8] It must be relatively easy for publishers to specify to the 433 management and observer their hint information as well as 434 any security constraints they need for their hints. 435 * The client 436 [R9] The interface to the RDS must be simple, effective, and 437 efficient; 438 [R10] The client and client applications must be able to understand 439 the information stored in and provided by the RDS easily, 440 in order to be able to make informed choices. 441 * The management 442 [R11] The management of hints must be as unobtrusive as possible, 443 avoiding using too many network resources; 444 [R12] The management of hints should allow for administrative 445 controls that encourage certain sorts of behavior deemed 446 necessary to meet other requirements; 447 [R13] The configuration and verification of configuration of 448 individual RDS servers must be simple enough not to 449 discourage configuration and verification. 451 Usability can be evaluated from three distinct perspectives: those of a 452 publisher wishing to make a piece of information public, those of a 454 - 8 - 455 client requesting URN resolution, and those of the provider or manager 456 of resolution information. We will separately address the usability 457 requirements from each of these three perspectives. 459 It is worth noting that there are two additional sorts of participants 460 in the whole naming process, as discussed in the URN WG. They are the 461 naming authorities which choose and assign names, and the authors who 462 include URNs in their resources. These two are not relevant to the 463 design of an RDS and hence are not discussed further here. 465 3.2.1 The Publisher 467 The publisher must be able to make URNs known to potential customers. 468 From the perspective of a publisher, it is of primary importance that 469 URNs be correctly and efficiently resolvable by potential clients with 470 very high probability. Publishers also stand to gain from long-lived 471 URNs, since they increase the chance that references continue to point 472 to their published resources. 474 The publisher must also be able to choose easily among a variety of 475 potential services that might translate URNs to location information. 476 In order to allow for this mobility among resolver services, the 477 architecture for resolver services specified within the IETF should 478 not result in a scenario in which changing from one resolver service 479 to another is an expensive operation. 481 The publisher should be able to arrange for multiple access points to a 482 published resource. For this to be useful, resolver services should 483 be prepared to provide different resolution or hint information to 484 different clients, based on a variety of information including location 485 and the various access privileges the client might have. For example, 486 companies might arrange for locally replicated copies of popular 487 resources, and would like to provide access to the local copies only for 488 their own employees. This is distinct from access control on the 489 resource as a whole, and may be applied differently to different copies. 491 The publisher should be able to provide both long and short term 492 location information about accessing the resource. Long term 493 information is likely to be such information as the long term or the 494 location or identity of a resolver service with which the publisher 495 has a long term relationship. One can imagine that the arrangement 496 with such a long term "authoritative" resolver service might be a 497 guarantee of reliability, resiliency to failure, and atomic updates. 498 Shorter term information is useful for short term changes in services 499 or to avoid short lived congestion or failure problems. For example, 500 if the actual repository of the resource is temporarily inaccessible, 501 the resource might be made available from another repository. This 502 short term information can be viewed as temporary refinements of the 503 longer term information, and as such should be more easily and quickly 504 made available, but may be less reliable. 506 Lastly, the publishers will be the source of much hint information that 507 will be stored and served by the manager of the infrastructure. Despite 508 the fact that many publishers will not understand the details of the RDS 509 mechanism, it must be easy and straightforward to install hint 511 - 9 - 512 information. The publisher must be able not only to express hints, but 513 also to verify that what is being served by the manager is correct. 514 Furthermore, to the extent that there are security constraints on hint 515 information, the publisher must be able to both express them and verify 516 compliance with them easily. 518 3.2.2 The Client 520 From the perspective of the client, simplicity and usability are 521 paramount. Of critical importance to serving clients effectively is 522 that there be an efficient protocol through which the client can acquire 523 hint information. Since resolving the name is only the first step on 524 the way to getting access to a resource, the amount of time spent on it 525 must be minimized. 527 Furthermore, it will be important to be able to build simple, standard 528 interfaces to the RDS so that both the client and applications on the 529 client's behalf can interpret hints and subsequently make informed 530 choices. The client, perhaps with the assistance of the application, 531 must be able to specify preferences and priorities and then apply them. 532 If the ordering of hints is only partial, the client may become directly 533 involved in the choice and interpretation of them and hence they must be 534 understandable to that client. On the other hand, in general it should 535 be possible to configure default preferences, with individual 536 preferences viewed as overriding any defaults. 538 From the client's perspective, although URNs will provide important 539 functionality, the client is most likely to interact directly only with 540 human friendly names (HFNs). As in direct human interaction (not 541 computer mediated), the sharing of names will be on a small, private, or 542 domain specific scale. HFNs will be the sorts of references and names 543 that are easy to remember, type, choose among, assign, etc. There will 544 also need to be a number of mechanisms for mapping HFNs to URNs. Such 545 services as "yellow pages" or "search tools" fall into this category. 546 Although we are mentioning HFNs here, it is important to recognize that 547 HFNs and the mappings from HFNs to URNs is and must remain a separate 548 functionality from an RDS. Hence, although HFNs will be critical to 549 clients, they do not fall into the domain of this document. 551 3.2.3 The Management 553 Finally, we must address the usability concerns with respect to the 554 management of the hint infrastructure itself. What we are terming 555 "management" is a service that is distinct from publishing; it is the 556 core of an RDS. It involves the storage and provision of hints to the 557 clients, so that they can find published resources. It also provides 558 security to the extent that there is a commitment for provision of such 559 security; this is addressed below. 561 The management of hints must be as unobtrusive as possible. First, its 562 infrastructure (hint storage servers and distribution protocols) should 563 have as little impact as possible on other network activities. It must 564 be remembered that this is an auxiliary activity and must remain in the 565 background. 567 - 10 - 568 Second, in order to make hint management feasible, there may need to 569 be a system for administrative incentives and disincentives such as 570 pricing or legal restrictions. Recovering the cost of running the 571 system is only one reason for levying charges. The introduction of 572 payments often has a beneficial impact on social behavior. It may be 573 necessary to discourage certain forms of behavior that when out of 574 control have serious negative impact on the whole community. At the 575 same time, any administrative policies should encourage behavior that 576 benefits the community as a whole. Thus, for example, a small 577 one-time charge for authoritatively storing a hint will encourage 578 conservative use of hints. If we assume that there is a fixed cost 579 for managing a hint, then the broader its applicability across the URN 580 space, the more cost effective it is. That is, when one hint can 581 serve for a whole collection of URNs, there will be an incentive to 582 submit one general hint over a large number of more specific hints. 583 Similar policies can be instituted to discourage the frequent changing 584 of hints. In these ways and others, behavior benefitting the 585 community as a whole can be encouraged. 587 Lastly, symmetric to issues of usability for publishers, it must also 588 be simple for the management to configure the mapping of URNs to 589 hints. It must be easy both to understand the configuration and to 590 verify that configuration is correct. With respect to management, 591 this requirement may have an impact not only on the information itself 592 but also on how it is partitioned among network servers that 593 collaboratively provide the management service or RDS. For example, 594 it should be straightforward to bring up a server and verify that the 595 data it is managing is correct. Although this is not a requirement, 596 it is worth nothing that since we are discussing a global and probably 597 growing service, encouraging volunteer participants suggests that, as 598 with the DNS, such volunteers can feel confident about the service 599 they are providing and its benefit to both themselves and the rest of 600 the community. 602 3.3 Security and Privacy Requirements 604 SUMMARY: Security and privacy requirements can be identified as some 605 degree of protection from threats. These requirements are all stated 606 in terms of possibilities or options for users of the service to 607 require and utilize. Hence they are requirements for the availability 608 of functionality, but not for the use of it. We recognize that all 609 security is a matter of degree and compromise. These may not satisfy 610 all potential customers, and there is no intention here to prevent 611 them from building more secure servers with more secure protocols to 612 suit their needs. These are intended to satisfy the needs of the 613 general public. 615 [R14] It must be possible to create authoritative versions of a hint 616 with access-to-modification privileges controlled; 617 [R15] It must be possible to determine the identity of servers or avoid 618 contact with unauthenticated servers; 619 [R16] It must be possible to reduce the threat of denial of service 620 by broad distribution of information across servers. 622 - 11 - 624 [R17] It must be possible within the bounds of organization policy 625 criteria to provide at least some degree of privacy for 626 traffic. 627 [R18] It must be possible for publishers to keep private certain 628 information such as an overall picture of the resources they are 629 publishing and the identity of their clients; 630 [R19] It must be possible for publishers to be able to restrict 631 access to the resolution of the URNs for the resources they 632 publish, if they wish. 634 When one discusses security, one of the primary issues is an 635 enumeration of the threats being considered for mitigation. The 636 tradeoffs often include cost in money and computational and 637 communications resources, ease of use, likelihood of use, and 638 effectiveness of the mechanisms proposed. With this in mind, let us 639 consider a set of threats. 641 A good place to begin is with the early work of Voydock and Kent 642 [VK83]. They identify unauthorized release of information as a 643 passive attack, and all three of unauthorized modification of 644 information, denial of service, and spurious association initiation as 645 active attacks. An intruder at any protocol layer can attack at any 646 of the links or computational elements (hosts, routers, etc.) at that 647 layer. Attacks at one layer can be achieved by subverting or 648 attacking the lower layers. An unauthorized release of information is 649 a violation of privacy or confidentiality. This may be achieved by a 650 release of the information itself. Additional passive threats are 651 from secondary information through traffic analysis or other 652 violations of transmission security, such as noticing lengths and/or 653 sources and destinations of traffic. Moving to the active threats, 654 unauthorized modification of information can be partitioned into 655 problems with authenticity, integrity and ordering. Denial of service 656 may take the form of discarding information before it reaches its 657 destination or some degree of delay in delivering information. 658 Finally, spurious association may occur when a previous legitimate 659 association initiation is played back or an initiation is made under 660 false identity. Security measures may take the form of either 661 detection or prevention of each of these threats. Within the scope of 662 this work, we must identify those threats that are both of concern and 663 that we expect to be able to mediate. Of these threats the prevention 664 of passive attacks is known to be a particularly difficult problem to 665 address in the general case. 667 Of these threats, the passive threats to privacy or confidentiality 668 and the active threats of authenticity and integrity are probably the 669 most important to consider here. To the extent that spurious 670 association causes threats to the privacy, authenticity, or integrity 671 with respect to information within servers managing data, it is also 672 important. Because updates to hint information are idempotent, at 673 least with short periods of time, we will set aside the problems of 674 ordering for this analysis. Denial of service is probably the most 675 difficult of these areas of threats both to detect and to prevent, and 676 we will therefore set it aside for the present as well, although it 677 will be seen that solutions to other problems will also mitigate some 678 of the problems of denial of service. Furthermore, because this is 680 - 12 - 681 intended to be provide a global service to meet the needs of a variety 682 of communities, the engineering tradeoffs will be different for 683 different clients. Hence the requirements are stated in terms of, 684 "It must be possible..." It is important to note that the 685 information of concern here is hint information, which by nature is 686 not guaranteed to be correct or up-to-date; therefore, it is unlikely 687 to be worth putting too much expense into the correctness of hints, 688 because there is no guarantee that they are still correct anyway. But 689 the exact choice of degree of privacy, authenticity, and integrity 690 must be determined by the needs of the client and the availability of 691 services from the server. 693 There is one further issue to address at this point, the distinction 694 between mechanism and policy. In general, a policy is realized by 695 means of a set of mechanisms. In the case of an RDS there may be 696 policies internal to the RDS that it needs to have supported in order 697 to do its business as it sees fit. Since, in general it is in the 698 business of storing and distributing information, most of its security 699 policies may have to do with maintaining its own integrity, and are 700 rather limited. Beyond that, to the degree possible, it should impose 701 no policy on its customers, the publishers and users. It is they that 702 may have policies that they would like supported by the RDS. To that 703 end, an RDS should provide a spectrum of "tools" or mechanisms that 704 the customers can cause to be deployed on their behalf to realize 705 policies. An RDS may not provide all that is needed by a customer. A 706 customer may have different requirements within his or her 707 administrative bounds than outside. Thus, "it must be possible..." 708 captures the idea that the RDS must generally provide the tools to 709 implement policies as needed by the customers. 711 The first approach to URN resolution is to discover local hints. In 712 order for hints to be discovered locally, they will be as widely 713 distributed to what is considered to be local for every locale. The 714 drawback of such wide distribution is the wide distribution of 715 updates, causing network traffic problems or delays in delivering 716 updates. An alternative model would concentrate hint information in 717 servers, thus requiring that update information only be distributed to 718 these servers. In such a model the vulnerable points are the sources 719 of the information and the distribution network among them. Attackers 720 on the integrity of the information stored in a server may come in the 721 form of other a fake owner of the information or a fake server to the 722 extent that servers exchange updates with each other. Wide 723 replication of information among servers increases the difficult of 724 masquerading at all the locations of the information as well as 725 reducing the threat of denial service. These lead us to three 726 identifiable goals for our security model: 728 * ACCESS CONTROL ON HINTS: It must be possible to create an 729 authoritative version of each hint with change control limited only 730 to those principals with the right to modify it. The choice of who 731 those principals are or whether they are unlimited must be made by 732 the publisher of a hint. 734 - 13 - 735 * SERVER AUTHENTICITY: Servers and clients must be able to learn the 736 identity of the servers with which they communicate. This will be a 737 matter of degree and it is possible that there will be more 738 trustworthy, but less accessible servers, supported by a larger 739 cluster of less authenticatable servers that are more widely 740 available. In the worst case, if the client receives what appears to 741 be unvalidated information, the client should assume that the hint 742 may be inaccurate and confirmation of the data might be sought from 743 more reliable but less accessible data. 745 * SERVER DISTRIBUTION: Broad availability will provide resistance to 746 denial of service. It is only to the extent that the services are 747 available that they provide any degree of trustworthiness. In 748 addition, the distribution of services will reduce vulnerability 749 of the whole community, by reducing the trust put in any single 750 server. This must be mitigated by the fact that to the extent trust 751 is based on a linked set of servers, if any one fails, the whole 752 chain of trust fails; the more elements there are in such a chain, 753 the more vulnerable it may become. 755 Privacy is a more difficult problem to address. It may be a 756 double-edged sword; for example, an organization may consider it 757 critically important that its competitors not be able to read its 758 traffic, while it may also consider it important to be able to monitor 759 exactly what its employees are transmitting to and from whom, for a 760 variety of reasons such as reducing the probability that its employees 761 are giving or selling the company's secrets to verifying that 762 employees are not using company resources for private endeavor. Thus, 763 although there are likely to be needs for privacy and confidentiality, 764 what they are, who controls them and how, and by what mechanisms vary 765 widely enough that it is difficult to say anything concrete about them 766 here. 768 The privacy of publishers is much easier to safeguard. Since they are 769 trying to publish something, in general privacy is probably not 770 desired. However, publishers do have information that they might like 771 to keep private: information about who their clients are, and 772 information about what names exist in their namespace. The 773 information about who their clients are may be difficult to collect 774 depending on the implementation of the resolution system. For 775 example, if the resolution information relating to a given publisher 776 is widely replicated, the hits to _each_ replicated copy will need to 777 be recorded. Of course, determining if a specific client is 778 requesting a given name can be approached from the other direction, by 779 watching the client as we saw above. 781 The other privacy issue for publishers has to do with access control 782 over URN resolution. This issue is dependent on the implementation of 783 the publisher's authoritative URN resolver server. URN resolver 784 servers can be designed to require proof of identity in order to be 785 issued resolution information; if the client does not have permission 786 to access the URN requested, the service denies that such a URN 787 exists. An encrypted protocol can also be used so that both the 788 request and the response are obscured. Encryption is possible in this 790 - 14 - 791 case because the identity of the final recipient is known (i.e. the 792 URN server). 794 4. The Framework 796 With these assumptions and requirements in mind, one can conclude with a 797 general framework within which RDS designs will fall. As stated 798 earlier, although this framework is put forth as a suggested guide for 799 RDS designers, compliance with it will in no way guarantee compliance 800 with the requirements. Such an evaluation must be performed separately. 801 It is also understood that there may be RDS services that do not meet 802 the requirements in clearly identified ways. This may be true 803 especially with early plans and experiments. For example, although a 804 careful threat analysis may have been done to understand security 805 requirements, not all those security requirements may be addressed, in 806 order to use existing facilities to allow for early deployment for 807 experimentation purposes. All such lack of compliance should be clearly 808 documented. 810 The design of the framework is based on a simple assumption about the 811 syntax of a URN a documented in RFC-XXX[RFCXXX}. This assumed syntax 812 is: 814 URN:: 816 where URN: is a prefix on all URNs, NID is the namespace identifier, 817 and NSS is the namespace specific string. The prefix identifies each 818 URN as such. The NID determines the general syntax for all URNs 819 within its namespace. The NSS is probably partitioned into a set of 820 delegated and subdelegated namespaces, and this is probably reflected 821 in further syntax specifications. In more complex environments, each 822 delegated namespace will be permitted to choose the syntax of the 823 variable part of the namespace that has been delegated to it. In 824 simpler namespaces, the syntax will be restricted completely by the 825 parent namespace. For example, although the DNS does not meet all the 826 requirements for URNs, it has a completely restricted syntax, such 827 that any further structuring must be done only by adding further 828 refinements to the left, maintaining the high order to low order, 829 right to left structure. A delegated syntax might be one in which a 830 host is named by the DNS, but to the right of that and separated by an 831 "@" is a string whose internal ordering is defined by the file system 832 on the host, which may be defined high order to low order, left to 833 right. Of course, much more complex and nested syntaxes should be 834 possible, especially given the need to grandfather namespaces. In 835 order to resolve URNs, rules will be needed for two reasons. One is 836 simply to canonicalize those namespaces that do not fall into a 837 straightforward (probably right to left or left to right) ordering of 838 the components of a URN, as determined by the delegated naming 839 authorities involved. It is also possible that rules will be needed 840 in order to derive from URNs the names of RDS servers to be used in 841 stages. 843 The NID defines a top level syntax. This syntax will determine 844 whether the NID alone or in conjunction with some extraction from the 845 NSS (for the top level naming authority name) is to be used to 847 - 15 - 848 identify the first level server to be contacted. At each stage of the 849 lookup either a new rule for generating the strings used in yet 850 another lookup (the strings being the identity of another RDS server 851 and possibly a string to be resolved if it is different than the 852 original URN) or a reference outside the RDS to a private URN 853 resolver service, sidestepping any further use of the RDS scheme. 854 Figure 1 depicts this process. 856 URN: 857 | 858 | 859 | 860 | 861 v 862 +-------------------+ 863 |Global NID registry| 864 +-------------------+ 865 | 866 | 867 | 868 (return rule or URN resolver service reference) 869 | 870 +----------------------------------+ 871 | | 872 +->(apply rule to determine RDS server) | 873 | | | 874 | | | 875 | | | 876 | +----------+ | 877 | |RDS server| +-----------------+ 878 | +----------+ | 879 | | | v 880 | | | (set of choices) 881 | | +----+----------(...)--------+ 882 | (rule) | | 883 | | | | 884 | | | | 885 +------+ | | 886 v v 887 +----------+ +----------+ 888 |private | |private | 889 |URN | |URN | 890 |resolver | |resolver | 891 |service | |service | 892 +----------+ +----------+ 894 Figure 1: An RDS framework 896 There are several points worth noting about the RDS framework. First, 897 it leaves open the determination of the protocols, data organization, 898 distribution and replication needed to support a particular RDS 900 - 16 - 901 scheme. Second, it leaves open the location of the computations 902 engendered by the rules. Third, it leaves open the possibility that 903 partitioning (distribution) of the RDS database need not be on the 904 same boundaries as the name delegation. This may seem radical to 905 some, but if the information is stored in balanced B-trees for 906 example, the partitioning may not be along those naming authority 907 delegation boundaries. Lastly, it leaves open access to the Global 908 NID Registry. Is this distributed to every client, or managed in 909 widely distributed servers? 911 One concept that has not been addressed in Figure 1 is that there may 912 be more than one RDS available at any given time, in order to allow 913 for evolution to new schemes. Thus, the picture should probably look 914 more like Figure 2. 916 URN:: 917 | 918 | 919 +-----------+-------(...)-------+ 920 | | 921 | | 922 | | 923 v v 924 +---------------------+ +---------------------+ 925 |Global NID registry 1| |Global NID registry N| 926 +---------------------+ +---------------------+ 927 . . 928 . . 929 . . 931 Figure 2: More than one co-existing RDS scheme 933 If we are to support more than one co-existing RDS scheme, there will 934 need to be coordination between them with respect to storage and 935 propagation of information and modifications. The issue is that 936 generally it should be assumed that all information should be available 937 through any operational RDS scheme. One cannot expect potential 938 publishers to submit updates to N RDS schemes. Hence there will need to 939 be a straightforward mapping of information from one to the other of 940 these schemes. It is possible that that transformation will only go in 941 one direction, because a newer RDS service is replacing an older one, 942 which is not kept up to date, in order to encourage transfer to the 943 newer one. Thus, at some point, updates may be made only to the newer 944 one and not be made available to the older one. Such a situation should 945 probably be avoided, if possible. 947 This framework is presented in order to suggest to RDS scheme 948 designers a direction in which to start designing. It should be 949 obvious to the reader that adherence to this framework will in no way 950 guarantee compliance with the requirements or even assumption 951 described in Sections 2 and 3. These must be reviewed independently 952 as part of the design process. There is no single correct design that 954 - 17 - 955 will meet these requirements. Furthermore, it is assumed that 956 preliminary proposals may not meet all the requirements, but should be 957 expected to itemized and justify any lack of compliance. 959 5. Acknowledgments 961 Foremost acknowledgment for this document goes to Lewis Girod, as my 962 co-author on a previous URN requirements document and for his insightful 963 comments on this version of the document. In addition, I recognize the 964 contributors to a previous URN framework document, the "Knoxville" 965 group. There are too many of you to acknowledge here individually, but 966 thank you. Finally, I must thank the contributors to the URN working 967 group mailing list (urn-ietf@bunyip.com), for their animated discussions 968 on these and related topics. 970 6. References 972 [RFC1736] Kunze, J., "Functional Recommendations for Internet Resource 973 Locators", RFC 1736, February, 1995. 975 [RFC1737] Sollins, K. and Masinter, L., "Functional Requirements for 976 Uniform Resource Names", RFC 1738, December, 1994. 978 [RFC1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform 979 Resource Locators (URL)", RFC 1738, December, 1994. 981 [RFCXXX] Moats, Ryan, "URN Syntax", currently available as 982 draft-ietf-urn-syntax-04.txt, March, 1997. 984 [VK83] Voydock, V. L., and Kent, S. T., "Security Mechanisms in 985 High-Level Protocols", ACM Computing Surveys, v. 15, No. 2, June, 986 1983, pp. 135-171. 988 7. Contact information: 990 Karen Sollins 991 MIT Laboratory for Computer Science 992 545 Technology Sq. 993 Cambridge, MA 02139 995 Tel: +1 617 253 6006 996 Email: sollins@lcs.mit.edu 998 This Internet Draft expires on September 28, 1997. 1000 - 18 -