idnits 2.17.1 draft-mealling-oid-dns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 561 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 177 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 23 instances of lines with control characters in the document. == There are 12 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 29 has weird spacing: '...ocument is a...' == Line 30 has weird spacing: '...cuments of t...' == Line 31 has weird spacing: '...F), its areas...' == Line 32 has weird spacing: '... other group...' == Line 36 has weird spacing: '...fts may be up...' == (11 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 22, 1995) is 10382 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) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Michael Mealling 2 INTERNET-DRAFT Georgia Institute of Technology 3 draft-mealling-oid-dns-00.txt Patrik Faltstrom 4 Bunyip Information Systems Inc. 5 Leslie L. Daigle 6 Bunyip Information Systems Inc. 7 November 22, 1995 9 Uniform Resource Names, ISO OIDs and DNS 11 ---------------------------------------- 12 Abstract 13 ---------------------------------------- 15 This paper describes a "resolution-mechanism"-independent architecture 16 for Unifrom Resource Name (URN) usage and name space management. This 17 non-monolothic architecture allows different components of the name space to be 18 managed by the appropriate level of network authority. This not only 19 integrates well with traditional Internet models, it allows flexibility in 20 choice of implementation of support for each layer of the name space. 22 An implementation for the architecture, using OIDs and DNS-based 23 infrastructure, is outlined. 25 ---------------------------------------- 26 Status of this draft 27 ---------------------------------------- 29 This document is an Internet-Draft. Internet-Drafts are 30 working documents of the Internet Engineering Task Force 31 (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of 36 six months. Internet-Drafts may be updated, replaced, or 37 obsoleted by other documents at any time. It is not 38 appropriate to use Internet-Drafts as reference material or 39 to cite them other than as a ``working draft'' or ``work in 40 progress.'' 42 To learn the current status of any Internet-Draft, please 43 check the 1id-abstracts.txt listing contained in the Internet- 44 Drafts Shadow Directories on ds.internic.net, nic.nordu.net, 45 ftp.isi.edu, or munnari.oz.au. 47 This Internet Draft expires June 9, 1996. 49 ---------------------------------------- 50 Introduction 51 ---------------------------------------- 53 This paper describes a "resolution-mechanism"-independent architecture 54 for Unifrom Resource Name (URN) usage and name space management. This 55 non-monolothic architecture allows different components of the name space to be 56 managed by the appropriate level of network authority. This not only 57 integrates well with traditional Internet models, it allows flexibility in 58 choice of implementation of support for each layer of the name space. 60 An implementation for the architecture, using OIDs and DNS-based 61 infrastructure, is outlined. 63 This paper has been revised to conform to the jointly-proposed URN syntax 64 that came out of the Knoxville meeting of URN system architects (October 30, 65 31, 1995). 67 ---------------------------------------- 68 Issues Concerning Uniform Resource Names 69 ---------------------------------------- 71 Apart from the basic requirements of Uniform Resource Naming, some specific 72 issues underly the architecture and implementation proposed in this paper: 74 1. One architecture to serve several communities 76 Historically, different communities have developed specialized naming 77 systems. For example, ISBNs and DNS evolved different architectures and 78 implementations as name spaces for different communities. Ideally, URNs 79 must accommodate name spaces from several different communities, and 80 should do so in a way that requires minimal changes to their name 81 spaces. 83 2. Persistence vs. transcribability of Uniform Resource Names 85 In order to achieve some degree of persistence of URNs over time (i.e., 86 to avoid the kinds of expiration problems that URLs have), the name space 87 has to be optimized for structure. However, arguments have been put 88 forward that suggest that URNs will not be usable if they are so 89 arbitrary and complex as to be meaningless to humans -- increasing the 90 number of transcription errors, etc. 92 3. Support for multiple URN resolution protocols 94 For pragmatic reasons, it is apparent that URN resolution should be 95 capable of supporting multiple protocols. In order to accomplish this 96 there must be some method to identify the name space and the resolution 97 protocol. Within a URN, the name space is identified by a scheme. 99 4. Modular vs. monolithic name space maintenance 101 URN resolution can be treated as a "black box" service -- given 102 a URN, return an information resource, a pointer, or some description 103 of the resource. However, to implement a resolution service in such 104 a monolithic fashion would require the maintainer of the service to 105 accurately track information at a very fine level of granularity. As 106 an alternative, a single name space can be handled in a modular fashion, 107 leaving authors closer to the maintenance of their documents, publishers 108 in charge of the editorial content of their collections, service 109 providers in charge of network details, etc. 111 One of the difficulties with more transcribable names is the very 112 semantics that are ascribed to the identifier strings. This has already 113 caused problems with domain name registration as people rush to register 114 domains that they expect will be sought after, law suits are launched over 115 the usage of particular phrases, etc. The proposed architecture addresses 116 these issues by separating out URN collection identifiers (which are 117 definitive, and not particularly prone to semantic interpretation by human 118 readers) and collection aliases (which are transmutable). This is 119 described in more detail below. 121 ---------------------------------------- 122 The Architecture 123 ---------------------------------------- 125 URN Syntax and Semantics 126 ------------------------ 128 The proposed URN syntax is as follows: 130 URN:[:] 132 where 134 URN indicates to the client (human or machine) that the rest of 135 the identifier conforms to URN standards (for distinguishability 136 of and , etc). 138 identifies the collection in which the resource 139 was originally published. URN syntax places no requirements 140 on the semantics of this identifier, although it is required 141 (for the sake of interoperability of all URN resolution systems) 142 that this be a hierarchical top-level-first slash-delimited name 143 of the authority that assigned the URN, and the name should, 144 through some transformation algorithm, be a valid DNS name. 146 : designated separator between collection name and the CUI 148 or "collection-unique identifier" is an identifier of no 149 globally-specified syntax or structure (opaque) that is only 150 required to be unique within the given collection. The CUI is 151 optional so that the collection itself can be identified. 153 Thus, URNs are globally unique by requiring that collection names are unique 154 across the URN name space. Pragmatically, this means that a collection name 155 is brought into existence once, by a collection publisher. Thereafter, 156 the rights to that collection name may be conferred to another publisher, 157 but only resources published by such authorized publishers will contain 158 that collection name, and these URNs will contain that collection name 159 for all time, irrespective of where the underlying resource migrates. 160 Individual collections are left to select object-identifiers in any way they 161 choose, as long as they are unique for that collection for all time. This 162 facilitates the incorporation of existing object name spaces -- an existing 163 library of information can assign URNs for its material by creating a collection 164 name and using the resources' existing names as the CUI. In order to be usable 165 as CUI strings, the only requirement placed on an object name space is that it 166 never reuse a name. If this is not inherently characteristic of the object name 167 space (e.g., as in file systems), the assigner of the name may choose to append 168 a unique suffix -- e.g., time stamp or serial number. 170 A sample URN might look like: 172 URN:/com/bunyip:a0n12a3r4b5i6t7r8a9r0y12o3p4a5q6u7e8s9t0r1i2n3g 174 It is proposed that the collection name may be either a Collection Alias 175 (preferred), or a Collection ID. The Collection Alias is a logical name for a 176 collection, while the Collection ID identifies definitively the entity that is 177 responsible for naming authority. Collection Aliases must be resolved into a 178 single Collection ID, although many aliases can exist for a single ID. 179 Collection IDs are associated with one or more resolution services (at 180 different sites, using different protocols, etc). 182 Note that the complete URN identifier consists of the combined collection 183 name and CUI strings. The distinction between the components is provided 184 in the syntax in order to permit the implementation of efficient support 185 mechanisms for partitioning the search space when resolving the URN. 186 That is, the collection's naming authority is the first logical place 187 to try to resolve the CUI. If that is not successful (discussed in more 188 detail below), the URN string remains a valid resource identifier; more 189 general resolution mechanisms must be applied across a larger portion of the 190 URN name space. 192 From URN to Resource... 193 ----------------------- 195 In the ideal case, the process of locating a resource identiried by a URN can 196 be represented as follows: 198 Collection Name 199 | 200 (one of) 201 +---------+----------+ 202 | | 203 v v 204 Collection Collection 205 Alias ID 206 | | 207 | | 208 | +----------+ 209 | | 210 | | 211 v v 212 +----------------+ Collection Alias, or Collection ID 213 | Collection |--------------+ [if previous was Collection Alias] 214 | Authority | | 215 | Identification | | 216 | Service |<-------------+ 217 +----------------+ 218 | 219 | (ranked in order of preference) 220 +------------------------------------+-----(...)------+ 221 | | | 222 v v v 223 Resolution Resolution Resolution 224 Service1 ID CUI Service2 ServiceN 225 | | 226 +------------+ 227 | 228 | 229 v 230 +----------------+ 231 | BrandX | 232 | URN | 233 | Resolution | 234 | Service | 235 +----------------+ 236 | 237 +-----+--------+-------------+---(...) 238 | | | 239 URL URC UR? 241 This process is proposed as a means of handling the URN identifier because 242 it provides modular layers of information management. From the standpoint 243 of the holder of a URN, this means that much of the underlying support 244 for a given URN or collection may change without disrupting the identification 245 capacities of the URN. For example, the resolution service(s) used by 246 a collection may move or change format entirely, without affecting the 247 validity of the URN. 249 Also, the information maintenance required for each level is isolated to 250 that level. The Collection Authority Identification Service is responsible for 251 maintaining the mapping information from Collection Aliases to Collection IDs, 252 and for Collection IDs to Resolution Service IDs. This can be done 253 straightforwardly by having each collection notify the Collection Authority 254 ID Service of any relevant changes -- which should be relatively 255 infrequent. Each Resolution Service is responsible for maintaining mapping 256 information from the CUI to the URx results. This will require 257 more frequent maintenance, but is localized to a single collection. The holder 258 of the resource at the end of the URx is responsible for that information 259 (e.g., the site holding the document accessible by a URL). As a result of 260 this modularity, each one of these services can be provided by completely 261 independent entities. 263 From Author to URN... 264 --------------------- 266 URNs are assigned through a publishing process. Details of the formality of 267 this process are up to the individual maintainers of collections, and 268 are not relevant beyond the requirement that they yield the unique identifier 269 as described above. Recall that a resource's URN includes the name of the 270 collection under which it was published, irrespective of where the resource 271 migrates over time. 273 From the author's perspective, a resource is published by submitting it 274 to a publisher. The publisher will store the resource in a collection (either 275 locally, or at some service it subscribes to) and thereafter undertakes to 276 maintain a copy of the resource. A CUI is assigned by the publisher (possibly 277 in conjunction with the collection's resolution service). This resolution 278 service may be run by the publisher, or may also be a service to which the 279 publisher subscribes, and so on up the levels. 281 The resource may be published under a Collection ID directly, or under 282 a Collection Alias. The latter case is preferred, since any given Collection 283 may use Collection Aliases to further partition and identify its resources. 284 It is also simpler to confer rights to an entire collection than it is 285 to handle migration of individual resources (discussed below), and it 286 is therefore interesting to keep a fairly fine-grained set of Collection 287 Aliases. 289 Life of a URN 290 ------------- 292 One of the highly desirable characteristics of URNs is their persistence 293 as identifiers of a resource. That is, the URN should not expire or become 294 unresolvable until or unless the resource to which it was assigned expires 295 or becomes irretrievable (and even then, it would be best of the system 296 could provide an indication of that condition). 298 The above architecture provides several degrees of freedom in terms of 299 the flexibility of the infrastructure that supports a given URN. For 300 example, if a collection authority changes the underlying resolution 301 service it uses, this simply yields a different reference when the 302 collection name is resolved. Similarly, if a Collection Alias is used 303 in the URN, the rights to the whole collection can be passed to another entity 304 with a completely different collection name authority -- the Collection Alias 305 now resolves to a new Collection ID. 307 However, this idealized architecture does not handle the case of collections 308 that are split at some point in time. The most obvious example of such 309 an occurrence would be if a single document migrates to another collection. 310 There are some implications of publishing that should reduce the number 311 of such occurrences (e.g., if the act of publishing includes the rights 312 to the material, the author cannot arbitrarily move the document to another 313 collection; arguably, if the author had wanted to maintain that control over 314 the resource, it should have been self-published). 316 Nevertheless, resources will migrate and collections will be split up. 317 In view of this fact, the Collection Name component of the URN can be 318 viewed as a guide as to where to look first for the resource. The goal 319 of a global Collection Authority Identifier Service is to provide 320 efficient shortcuts to the source of the resource in as many cases as 321 possible. Two things can be done to handle other cases: 323 1. The resolver can pass back new URNs, when the collection authority 324 remains "friendly" to the migrated resource 326 2. A global index of "orphaned" URNs can be maintained. 328 The latter option is to be avoided if at all possible because it carries 329 several inherent difficulties that may be exacerbated over time: 331 . distance from original author => reduced likelihood of accurate 332 and up to date information regarding resource 334 . it will only grow... 336 The first option is proposed because, although it may be assumed that the 337 newer the URN, the less likely it is to be "orphaned", it is not appropriate 338 to assume that old URNs will be accessed only infrequently -- there are 339 definitive versions of some types of resources. Therefore, it would be useful 340 to have the ability to refer enquiries from the original Collection 341 to a newer collection, with the expectation that the client would perform 342 necessary updates and that the number of such referrals would decrease over 343 time. 345 ---------------------------------------- 346 An Implementation 347 ---------------------------------------- 349 A Practical Implementation of Collection Identifiers 350 ---------------------------------------------------- 352 Since the proposed URN syntax requires that the collection name be 353 algorithmically mappable to a valid DNS name, it is tempting to consider 354 using either the existing DNS name space or one loosely based on it by 355 starting with a new hierarchy but still attempting to use existing names. 356 This may work for small publishers that have very simple name spaces but large 357 organizations with multiple levels of "resource promotion" or movement of 358 authority will have trouble with semantically incorrect names in URNs. For 359 example, if Microsoft purchased Intuit and the rights to all of its URNs, 360 those URNs that have the string "intuit" in the authority portion of the string 361 are semantically incorrect because the entity "Intuit" has ceased to exist. 363 Nevertheless, DNS is already deployed across the globe, and is recognized 364 as a system that has been designed (and is being improved) to support 365 resolution of global name spaces. It is therefore interesting to consider 366 leveraging its strengths for URNs. 368 We now consider a semantically unbiased name space that can be mapped into 369 DNS. This name space should have few rules regarding name assignment. In order 370 to have Collection IDs that are free from human-ascribable semantics (as 371 described above) it seems reasonable to assume that the character set must be 372 limited to either all numbers or a few numbers and letters (ala hex). It is also 373 desired that the rules concerning name assignment be only structured to the 374 extent that sub-authorities can be assigned. 376 These two preferences allow several solutions, but an existing name space 377 would be preferable since it facilitates acceptance. One existing solution is 378 the International Standards Organization Object Identifier or OID which has been 379 used by the IETF for several years in identifying MIBs and other objects. 380 OIDs are based on a hierarchical name space using only numbers delimited by 381 periods with the right most element being most significant. This is how OIDs 382 have been broken down for use by the IETF for various functions: 384 1 iso 385 1.3 org 386 1.3.6 dod 387 1.3.6.1 internet 388 1.3.6.1.1 directory 389 1.3.6.1.2 mgmt 390 1.3.6.1.2.1 mib-2 391 1.3.6.1.2.1.2.2.1.3 ifType 392 1.3.6.1.2.1.10 transmission 393 1.3.6.1.2.1.10.23 transmission.ppp 394 1.3.6.1.2.1.27 application 395 1.3.6.1.2.1.28 mta 396 1.3.6.1.3 experimental 397 1.3.6.1.4 private 398 1.3.6.1.4.1 enterprise 399 1.3.6.1.5 security 400 1.3.6.1.6 SNMPv2 401 1.3.6.1.7 mail 403 Delegation of authority is unspecified and thus is left up to the owner of a 404 given portion of the hierarchy. For example, 1.3.6.1.4.1.636 is 'owned' by 405 The Georgia Institute of Technology. It could as easily be owned by the 406 Library of Congress. Also, at this time delegation below that is by 407 department. If this organization of authority changes then no change must 408 occur in the name because it is transparent. 410 Another important feature of OIDs is that they are recognized by ISO and thus 411 are an internationally recognized standard. 413 DNS as a practical implementation of a Collection Authority ID Service 414 ---------------------------------------------------------------------- 416 The proposed URN syntax requires that the collection name component 417 be mappable onto a valid DNS name. While this does not mean that the 418 collection name is in any way required to be resolvable to a site name, 419 the DNS infrastructure can be used to support URN resolution. The existing 420 Domain Name System used extensivly on the Internet is by far the largest and 421 most accessible distributed database in the world. The Internet's reliance on 422 it means that most Internet-aware software is already primed with the ability 423 to interact with DNS. For this reason it is a good candidate for one of the 424 possible implementations of a Collection Authority ID Services. 426 When resolving an OID, we get information about what service to use when 427 resolving other data bound to the OID. You also get the hostname and port 428 number of the server itself. We call this information a Naming Authority 429 Pointer (NAPTR) record. 431 Each OID gives us a record with enough data to be know what resolution 432 service that organization, or part of that organization, uses. Note that if 433 one organization uses several resolution services, they can simply delegate 434 OIDs, one for each service, for the different resolution methods. 436 Collection Aliases, or User Friendly Naming 437 ------------------------------------------- 439 We also introduce the concept of a UFN ("User Friendly Name" -- since OIDs 440 are not) record in DNS to handle Collection Aliases. (There is no relationship 441 between this User Friendly Name and a User Friendly Name in X.500). 443 The UFN itself doesn't have to have the same meaning as the OID, i.e. we can 444 use this aliasing as a mechanism for having the UFN name the publisher, and 445 the OID name the authority which is responsible for the name delegation. This 446 makes it easy to allow publishers to purchase resolution services from 447 entities more suited to the task. 449 As an example, suppose Acme, Inc. decides to be a publisher of culinary recipes 450 and treatises on obscure points of international law. URNs for the material in 451 these collections could take the form: 453 URN:/com/acme/recipe: 455 URN:/com/acme/intlaw: 457 The decision to identify an entity as a publisher is distinct from 458 undertaking to maintain an operational URN resolution service. That is, if 459 Acme does decide to run its own service, the UFNs recipe.acme.com and 460 intlaw.acme.com will map to the OID for Acme, Inc. On the other hand, 461 if Acme, Inc. decides that running such a service requires more Internet 462 expertise and/or service than they can supply (e.g., Acme is in fact a 463 cottage industry run out of a cabin in backwoods Vermont), it can pay 464 for resolution services from a provider that specializes in them. In that 465 case, the UFN will map to the provider's OID, and resolution will continue 466 by identifying the types and locations of the provider's resolution services. 468 For example, the UFN bunyip.com can map to the OID for Bunyip, 469 1.3.6.1.4.1.1375, but if Bunyip is not interested in managing the OID 470 name space, the UFN bunyip.com can map onto the OID for The Georgia Institute 471 of Technology. This means that when we resolve the UFN bunyip.com, we are 472 referred to 1.3.6.1.4.1.636 for further resolution of other data bound to 473 the bunyip.com UFN. 475 This flexibility can also facilitate other things like promotion to library 476 grade cataloging and management. It supports persistence of URNs by 477 encapsulating certain maintenance responsibilities at different levels in 478 the name space. For example, if Acme, Inc. goes out of business, its recipe 479 and international law collections can be moved elsewhere (or made part of 480 another collection), and all that needs to change is the registration that 481 maps the UFNs recipe.acme.com and intlaw.acme.com to an OID. In fact, the two 482 collections can be taken over by 2 separate entities, and the UFNs may now map 483 to distinct OIDs. The semantics understood by users hasn't changed. The 484 name space management has adapted to a very pragmatic approach to supporting 485 the continued existence of a collection. 487 The UFN record is syntactically (and implementably) identical to the 488 current CNAME resource record except that it is not burdened with CNAMEs 489 restrictive semantics. For example, it is not possible to have both a 490 CNAME record and any other kind of DNS record (e.g., MX record) for one 491 domain name in DNS. (This is one reason why UFN records are proposed, 492 instead of continuing to use CNAME records). A UFN and an MX record can be 493 intermixed with no side effects. 495 The NAPTR gives the information needed, given an URN collection name, needed 496 for further resolution of the CUI in a URN. The information given is the: 498 precedence - to allow the client to choose among 499 multiple NAPTR records for a Naming 500 Authority. An unsigned short. Multiple 501 records can mean several possible things: 503 a) the NA offers multiple resolution 504 methods. Each method gets its own 505 preference as specified the the 506 resolving agent. 508 b) the NA offers multiple resolving 509 servers around the net as a load 510 sharing mechanism. 512 c) a combination of a and b 514 d) an unspecified reason 516 Client software should choose the record of 517 lowest-precedence that has a 'scheme' (see below) 518 that it recognizes. Beyond that, client developers 519 should not infer any global semantics of 520 precedence numbers. 522 algorithm - The resolution method used to resolve the 523 end service. Current examples would be 524 'path','whois++','handle','x-dns-2'. These 525 do not specify the actual protocol used to 526 finally resolve the CUI but instead specify 527 the next step in the resolution process. 528 For example, the client looks up /a/b/c/d and 529 finds that the method is 'path'. At that point 530 the client can assume that it can follow the 531 standard path resolution mechanisms. If instead 532 it had found 'handle' it could then assume that 533 it could contact the root and such as prescribed 534 by the handle method. 536 host - a DNS compresses hostname to connect to for this service. 538 port - The port connect to on 'hostname'. An unsigned short. 540 method-specific-string - a text field that only has meaning when 541 coupled with the algoirthm from above. For example, 542 if the algorithm were 'path' then this would be 543 the place in which a string specifying variable 544 substitution could be found. If the algorithm were 545 'whois++' it might contain the whois++ server name 546 or a template name. 548 It is important to bear in mind that the Collection Alias concept in 549 the proposed architecture allows mapping from any kind of name to any other 550 kind of name. This can be used by other (non-DNS-space) name spaces to map 551 onto OIDs, or indeed for DNS-space names to map onto other name spaces. 552 To distinguish a Collection Alias from a real Collection ID within a URN, we 553 simply require that any URN authority field must, after 1 or more iterations 554 through the Collection Authority ID Service, map to something that is 555 identified as a bona fide Collection ID. 557 ---------------------------------------- 558 Examples 559 ---------------------------------------- 561 Suppose the UFN bunyip.com is resolved by a Whois++ service at The Georgia 562 Institute of Technology, but some Georgia Tech departments use other resolution 563 services. Georgia Tech uses the OID 1.3.6.1.4.1.636.1 for Whois++, 564 1.3.6.1.4.1.636.2 for DNS etc. The bunyip.com UFN therefore refers to the 565 OID 1.3.6.1.4.1.636.1, and when looking up information about that OID, we get 566 the following information: 568 OID: 1.3.6.1.4.1.636.1 569 Preference: 10 570 Service: WHOIS 571 Hostname: mordred.gatech.edu 572 Portnr: 63 574 To be as flexible as possible in supporting multiple resolution services, 575 we also introduce a Preference on the NAPTR record. In this way, a single OID 576 can resolve to several NAPTR records, each with a different metric. This 577 is the same way MX records are handled in DNS. The record with the 578 lowest metric is to be used first, and if that fails, the second lowest is 579 used etc. It is important to realize that the actual value or original 580 meaning of the of the metric is inaccessible and inherently nonportable. 581 It is therefore not recommended to make assumptions about given 582 reference metrics. 584 This gives us another method to implement the above possible need for 585 multiple resolution services. Let's say that for redundancy and customer 586 service reasons Bunyip wishes to provide all possible method of URN 587 resolution but that it prefers whois++. It therefore puts several NAPTR 588 records in with different resolution scheme/preference pairs. 590 If the bunyip.com UFN is mapped to the OID 1.3.6.1.4.1.636.1, that in turn 591 can map into these two NAPTR records: 593 OID: 1.3.6.1.4.1.636.1 594 Preference: 10 595 Service: WHOIS 596 Hostname: mordred.gatech.edu 597 Portnr: 63 599 OID: 1.3.6.1.4.1.636.1 600 Preference: 20 601 Service: HTTP 602 Hostname: mordred.gatech.edu 603 Portnr: 80 605 We can resolve the collection name into a number of UFN or NAPTR records. 606 If it is a UFN then it is further resolved into a Collection ID name 607 which is then queried for an NAPTR record. Each NAPTR record is then used 608 in the order the Preference states to resolve the CUI in the URN. 610 The full resolution process is now: 612 Get the URN 613 Look up the Collection Name of the URN and ask for both UFN and NAPTR 614 records. 615 If there is a valid UFN record for this then 616 Look up one or several NAPTR records that the UFN points to; 617 else if there is one or more valid NAPTR record for this then 618 fall through; 619 else die; 621 For each NAPTR found above, 622 contact the services in the order specified by the Preference, 623 Look up a URC using the CUI 624 until we have a URC 626 An example DNS entry follows: 628 bunyip.com. IN UFN 1.3.6.1.4.1.636.1 630 1.636.1.4.1.6.3.1.oid.urn.net. IN NAPTR ( 631 10 ; metric 632 mordred.gatech.edu. ; hostname 633 63 ; port nr 634 "whois" ; protocol 635 "GATECH01" ) ; auxiliary data for Whois 637 or 639 gatech.edu. IN UFN 1.3.6.1.4.1.636.1 640 oit.gatech.edu. IN UFN 1.3.6.1.4.1.636.5.3 642 636.1.4.1.6.3.1.oid.urn.net. IN NAPTR ( 643 10 ; metric 644 mordred.gatech.edu. ; hostname 645 63 ; port nr 646 "whois" ; protocol 647 "GATECH01" ) ; auxiliary data for Whois 649 636.1.4.1.6.3.1.oid.urn.net. IN NAPTR ( 650 20 ; metric 651 mordred.gatech.edu. ; hostname 652 80 ; port nr 653 "http" ; protocol 654 "text/urc" ) ; auxiliary data for HTTP 656 3.5.636.1.4.1.6.3.1.oid.urn.net. IN NAPTR ( 657 10 ; metric 658 fuzzy.oit.gatech.edu. ; hostname 659 80 ; port nr 660 "http" ; protocol 661 "text/urc" ) ; auxiliary data for HTTP 663 Let's say that the very small company Acme Inc has published some materials 664 which they want to give a URN. They have unfortunately not registered a OID 665 yet, so they buy a OID space from the company Publish It Inc. They register 666 this by creating a UFN record which points from acme.com to 667 1.3.6.1.4.1.4711.13 which is an OID delegated from the Publish It Inc OID 668 (1.3.6.1.4.1.4711). 670 But, the company Publish It Inc is not connected to the Internet, so the 671 registration of the different documents is done by the company Big Net. The 672 NAPTR record therefore points to the Whois++ server at the company Big Net, 673 and they actually runs a separate Whois++ server for the documents of 674 Publish It Inc on port 7070. 676 The Big Net company in turn cooperates with the network provider Small Net. 677 They both mirror each others databases each night to be able to let their 678 customers use the other companies servers if their own have crashed. So, 679 they run secondary nameserver, secondary MX and secondary NAPTR records for 680 each other. 682 The UFN and the NAPTR records therefore looks like this: 684 acme.com. IN UFN 1.3.6.1.4.1.4711.13 686 13.4711.1.4.1.6.3.1.oid.urn.net. IN NAPTR ( 687 10 ; metric 688 server.nic.big.net. ; hostname 689 7070 ; port nr 690 "whois" ; protocol 691 "BIGNET01" ) ; auxiliary data for Whois 693 13.4711.1.4.1.6.3.1.oid.urn.net. IN NAPTR ( 694 20 ; metric 695 nic.small.net. ; hostname 696 6212 ; port nr 697 "whois" ; protocol 698 "SMALLNET01" ) ; auxiliary data for Whois 700 ---------------------------------------- 701 Final Remarks 702 ---------------------------------------- 704 The point of determining a common URN syntax at the Knoxville meeting 705 was to promote interoperability of different URN-resolving strategies. 706 This paper presents one such strategy, and proposed implementation structures 707 for URNs. Of course, this strategy is not limited to use by OIDs. Within DNS 708 any name can have an NAPTR record. This facilitates use of this resolution 709 method by any hierarchical, DNS accessible name space. We know the difference 710 between a UFN and a real URN authority by which record is returned for a DNS 711 query. 713 It is also important to realize that the use of DNS is not necesary for this 714 scheme to work. It is possible to use protocols like Whois++ for each one of 715 the steps as long as you can, given a something like a UFN, get a real 716 authority, and given a real authority get one or several things like an NAPTR 717 record. The decision to use Whois++ over DNS, or vice versa, is in the 718 hands of the client software writer. The important step here is to provide 719 at least _one_ URN-resolution name space management and resolution 720 infrastructure, without precluding the evolution of others. 722 ------------------------------------------------------------------------------ 724 "The Relentless Pursuit of Perfection Leslie Daigle 725 is a depth-first search of the infinitely deep leslie@bunyip.com 726 tree of life's experiences." Montreal, Canada 727 -- ThinkingCat 729 ------------------------------------------------------------------------------