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