idnits 2.17.1 draft-sun-handle-system-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 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 607 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 11 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 30 has weird spacing: '... system for a...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 16, 1998) is 9413 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2044 (ref. '2') (Obsoleted by RFC 2279) ** Obsolete normative reference: RFC 1738 (ref. '3') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 1737 (ref. '9') ** Downref: Normative reference to an Informational RFC: RFC 1630 (ref. '10') ** Obsolete normative reference: RFC 2168 (ref. '11') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Downref: Normative reference to an Historic RFC: RFC 2169 (ref. '12') ** Obsolete normative reference: RFC 2141 (ref. '13') (Obsoleted by RFC 8141) -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' ** Obsolete normative reference: RFC 2234 (ref. '21') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' Summary: 17 errors (**), 0 flaws (~~), 3 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Sam X. Sun 2 INTERNET-DRAFT CNRI 3 Expires Jan, 16, 1999 July 16, 1998 4 draft-sun-handle-system-01.txt 6 Handle System: A Persistent Global Name Service 7 Overview and Syntax 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 To learn the current status of any Internet-Draft, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 25 (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 26 Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 The Handle System (r) is a comprehensive system for assigning, 31 managing, and resolving persistent identifiers, known as 32 'handles' for digital objects and other resources on the Internet. 33 Handles can be used as Uniform Resource Names (URNs). The Handle 34 System defines:(a) an open set of protocols, (b) a global namespace, 35 and (c) a distributed service model that provides the global name 36 service. The system allows Internet resources to be named as handles. 37 A handle may contain the information necessary to locate and access 38 its named resources. This associated information can be changed as 39 needed to reflect the current state of the identified resource 40 without changing the handle, thus allowing the name of the item to 41 persist over changes of location and other state information. 42 Combined with a centrally administered naming authority registration 43 service, the Handle System provides a general purpose, distributed 44 global name service for the reliable management of information on 45 networks over long periods of time. (Note that in this document we 46 do not attempt to distinguish between the terms 'name' and 47 'indentifier' and will use them interchangably.) 49 1. Introduction 51 The Handle System is a distributed information system that provides 52 a persistent naming service for use on networks such as the 53 Internet. Handles can be used to identify any network resources. 55 Each handle may be assigned with a set of typed values that describes 56 its named object. The Handle System provides the handle resolution 57 service that allows these values to be retrieved. It also provides 58 the handle administration service that allows individual handles to 59 have their own administrator(s) assigned, and be administrated over 60 the distributed environment. 62 The Handle System ensures that every handle is unique within the 63 context of the Handle System and may be retained and resolved over 64 long time periods. The resolution information associated with each 65 handle can be changed as needed, allowing the handle to persist over 66 changes in location and other states of the named resource. 68 Specifically, the Handle System was designed to address the 69 following problems in network resource identification: 71 * Persistence 73 A named resource can outlast any specific computer system or 74 organization. Any resource name which is inextricably linked 75 with a specific system or name of an organization will not be 76 able to survive the demise or radical change of that computer 77 system or organization. By separating the object's name from 78 location, ownership, and other state information, the Handle 79 System allows that identifier to persist over time. 81 * Location independence 83 With handles, the name of the item is unrelated to the location 84 of the item. This allows easy reorganization of information. 85 Handles make it possible to transfer resources from one 86 organization to another without affecting or breaking the 87 existing user references (i.e., handles) to those collections. 88 This is not possible using location based references. 90 * Multiple instances of an item 92 A single handle can refer to more than one instance of a network 93 resource. A network service may thus define multiple entry points 94 for its service with a single handle name. This allows the service 95 to distribute its service load into multiple instances. 97 The Handle System has been implemented and is currently in use in 98 a number of prototype projects, including efforts with the Library 99 of Congress, the Association of American Publishers, the Defense 100 Technical Information Center, and the United States Information 101 Agency. 103 This is the first of a series of planned documents that will 104 specify the handle protocol and services, and relate the Handle 105 System to other IETF activities in URN/URI/URL working groups. 106 This document provides a concise overview of the system and the 107 syntax of handles. Additional information can be found on CNRI 108 and related project web sites [4, 5, 6, 8, 16, 17, 18, 19]. 110 2. Handle Syntax 112 Every handle in the Handle System is defined in two parts: 113 its naming authority, otherwise know as its prefix, and a unique 114 local name under that naming authority, otherwise known as its 115 suffix. The Handle System protocol mandates UTF-8 [2] as the only 116 encoding for any handles specified in the protocol packet. 118 The naming authority identifies the administrative unit of the 119 underlying handles. It is globally unique and will be persistent 120 once obtained. Naming authorities may consist of any UTF-8 encoded 121 characters defined in the Unicode 2.0 [1] standard except '.' 122 (%x0E) or '/' (%x2F). ASCII characters in the naming authority 123 are case insensitive and are converted into upper case before 124 resolution taking place. 126 The local name under the naming authority may consist of any 127 UTF-8 encoded characters defined in the Unicode 2.0. It does not 128 impose any reserved or excluded characters. ACSII characters 129 within the local name are case insensitive, and are converted 130 into upper case before resolution taking place. 132 The following is the handle syntax described in ABNF [21] 133 notation: 135 = "/" 137 = *( "." ) 139 = 1*( %x00-FF ) 140 ; any octets that map to UTF-8 encoded 141 ; Unicode 2.0 characters. 143 = 1*( %x00-2D / %x30-FF ) 144 ; any octets that map to UTF-8 encoded 145 ; Unicode 2.0 characters except octets 146 ; %x2E-2F which map to ASCII characters 147 ; '.' and '/'. 149 Here are some examples of valid handles that may be used in the 150 Handle System protocol: 152 cnri.dlib/july95-arms 154 10.1002/0002-8231(199601)47:1<1:SPOTEO>2.3.TX;2-K 156 any-printable-characters/a-zA-Z0-9!@#$%^&*()_"<>,.?/`~|\ 158 handles-in-germany/Universit~{#?~}-Karlsruhe 160 3. Handle data 162 A handle within the Handle System is associated with, and can 163 be resolved to, one or more elements of typed data. Examples of 164 data types in use include URLs, object request brokers, and 165 other URNs. Other examples might include e-mail addresses or 166 public key certificates. There is a controlled set of named 167 types accepted by the system. This list can be extended as 168 needed at the system level. 170 Each handle will also have its administrative data. The 171 administrative data, e.g., permissions to create handles or 172 edit handle data, is initially provided by the handle server when 173 the handle was first created. The administrative data can be used 174 to define the handle administrator that manages the handle data. 175 This administrative data is not returned as part of the handle 176 resolution but is used for handle administration only. 178 Other than the relationship between the Global Handle Registry 179 and local handle services described above, there are no 180 hierarchical relationships assumed among handle records. Note, 181 however, that handles can include in their associated data 182 references to other handles, thus allowing hierarchical or other 183 relationships to be constructed as needed. 185 4. Using Handles in the World Wide Web 187 4.1 Handle URI syntax 189 The Handle Syntax in section 2 defines the encoding rules for 190 handles transferred over the wire via the Handle System protocol. 191 Handles may also be referenced as a URI [22], which can be used in 192 Web browsers or in HTML mark-up documents to refer to persistent 193 Internet resources. The Handle URI syntax defines the syntax 194 rule for handles specified in the URI format. 196 Handles defined as a Handle URI may be resolved by the Handle 197 System Resolver [4]. The Handle System Resolver will convert the 198 URI into the Handle (as defined in section 2) before doing the 199 resolution. 201 The Handle URI Syntax is defined as follows: 203 = "hdl:" [ "@" ] 205 = [ ] [ "type=" ] 207 = 1*40( %x01-7F ) 208 ; A registered charset name [23] from IANA, 209 ; which may be any printable ASCII characters. 211 = 1*(%x30-39) 212 ; digits 0 - 9. 214 = 1*( %x00-%xFF ) 215 ; Octets that encodes a using the 216 ; in the optional . 217 ; If no specified, UTF-8 encoding 218 ; is the default encoding. 220 When UTF-8 is the encoding used, the Handle URI Syntax has two 221 reserved characters, % and ". The character % is used for hex encoding, 222 which is necessary to allow any handles specified from the standard 223 keyboard. And the character " is reserved to allow handles to be 224 separated from the surrounding text in HTML documents. Reserved 225 characters must be hex encoded when used in the URI context. The 226 choice of % and hex encoding is also compatible with the current URI 227 practice. Because some browser implementation (incorrectly!) drops 228 the # character when processing the URI regardless of its scheme, hex 229 encoding of character # is also recommended. 231 Examples of handles using Handle URI Syntax are: 233 hdl:cnri.dlib/july95-arms 235 (which refers to handle "cnri.dlib/july95-arms") 237 and 239 hdl:handle-with-hex-encoding/handle%25abc 241 (which refers to handle "handle-with-hex-encoding/handle%abc") 243 It's worth noting that the handle namespace by itself does not 244 impose any hex or escape encoding, nor does the underlying 245 Handle System. The reserved characters and hex encoding are 246 introduced only when handles are used in the URI context. It is 247 the client software's responsibility to decode any hex encoding 248 in the handle URI before sending the handles out for resolution. 249 And on systems where other character set encoding is used, it is 250 also the client software's responsibility to convert a natively 251 displayed handle to its UTF-8 encoding before sending it out 252 for resolution. 254 4.2 Handle Resolution service from Web browsers 256 Handles specified using Handle URI Syntax (ie, hdl:) 257 can be resolved from a Web browser directly using the Handle 258 System Resolver [4]. The Resolver is a freely available 259 extension to the current popular Web browsers. It resolves 260 handles into corresponding URIs, which are then retrieved by 261 the browser in the normal fashion. This is the suggested way 262 to resolve the handles in the future, because it provides 263 better performance, is more scalable, and is locally 264 configurable. 266 Handles can also be resolved using proxy services using Handle 267 Proxy Syntax (ie, http:/). In this case, the 268 proxy server performs the handle resolution task, and sends 269 the resulting URL to the client browser for processing. 270 Currently, CNRI provides global handle proxy server through 271 "hdl.handle.net", and "dx.doi.org". The proxy server allows 272 handles to be resolved without additional software for the 273 client. For example, a handle "cnri.dlib/july95-arms" may be 274 entered as "http://hdl.handle.net/cnri.dlib/july95-arms" 275 resolvable by any browser. 277 It is worth noting that even though using the proxy server 278 approach is straight-forward and doesn't require any customer 279 software customization, it has the effect of connecting the 280 handles with the proxy server's URL location. Hence the 281 selection of a proxy server should be made with care. 283 4.3 Creating handles for network resources 285 The Handle System allows handles to be created in a distributed 286 fashion. Organizations in need of providing a naming service 287 for their persistent internet resources will be able to contact 288 CNRI or other organizations to register for their own handle 289 naming authority, as well as their own local handle services. 290 This will enable them to create handles for their own 291 organizational use. Policies and procedures for Naming Authority 292 registration are currently under development. 294 As an initiative for general public service, CNRI has established 295 a public handle registration service for the IETF community. This 296 service provides an open channel to allow individuals to create 297 handles and experiment with the handle system. The service is 298 provided for testing purposes only. Future availability of this 299 service is not guaranteed. Details on how to use this service, as 300 well as its terms and conditions can be obtained from 301 http://www.handle.net/ietf/handle/register_handle.html. 303 5. Handle System Service Architecture 305 The Handle System is distributed, scalable, and designed for 306 widespread deployment. The current implementation consists of one 307 global service and many local handle services. Each handle 308 service consists of one of more physically distributed handle 309 servers. (Currently, the global service consists of two servers 310 in Virginia and two in California. A European location is 311 planned.) And each handle server can have one or more secondary 312 servers for mirroring. In addition, handle caching servers are 313 provided for faster resolution service for a local environment, 314 and they can also be used to provide proxy service through 315 firewalls. 317 5.1 Handle services 319 The Handle System consists of many services. Each service is 320 responsible for part of the handle namespace. One specific 321 service, called the Global Handle Registry, is globally unique, 322 and has a special function, which is to know of the existence, 323 location, and namespace responsibilities of all other public 324 services, or local handle services. There can be an unlimited 325 number of local handle services, managed by various organizations. 326 In the current implementation each local handle service is 327 registered with the Global Handle Registry to ensure efficient 328 resolution. Policies and procedures for disconnected local handle 329 services are under development. The primary issue here is to 330 guarantee identifier uniqueness in disconnected systems. 332 5.2 Handle servers within a service 334 Each handle service consists of one or more handle servers. 335 Typically, each handle server runs on a separate computer but 336 multiple handle servers can run on a single computer. Within a 337 handle service, the distribution of handles across its constituent 338 servers is determined by a hash table such that each of N servers 339 within a service will be responsible for 1/N handles. The number 340 of servers can be adjusted as required to meet the needs of a 341 service. 343 5.3 Server replication 345 Additionally, it may be desirable to mirror the contents of any of 346 the handle servers within a service, presumably on a separate 347 computer. This is referred to as replication and is accomplished 348 by creating one or more additional servers whose sole purpose is 349 to mirror the contents of the original server. Within each set of 350 replicated servers, the initial server is called the primary server 351 and all others are called secondary servers. The creation and 352 administration of handles always takes place on the primary server, 353 but resolution can use either the primary or any of its secondaries. 354 This provides fault tolerance, as well as the potential for 355 performance improvement. 357 5.4 Caching Server 359 The Handle System Caching Server has been built to reduce the 360 network traffic between handle clients and handle services and 361 its use is strongly encouraged. Caching handle data or routing 362 information on the caching server allows some handle resolution 363 to be performed within an organization's local area network. 365 5.5 Proxy Server 367 The Handle System Proxy Server has been developed to act as a 368 client to the Handle System, allowing handles to be resolved using 369 Handle Proxy Syntax (ie, http:/). Using 370 this syntax, the browser passes a handle to the proxy server, 371 which in turn passes the handle to the appropriate handle 372 service for resolution. If the handle can be resolved into one 373 or more URLs, a URL is returned from the handle 374 server to the proxy, and from the proxy to the client browser. 376 5.6 Handle System Resolver 378 The Handle System Resolver [4] is a software component which 379 extends Netscape or Microsoft Web browsers, and allows handles 380 to be resolved using Handle URI Syntax (ie, hdl:). Using 381 this syntax, the browser passes the handle directly to the 382 appropriate handle service for resolution. If the handle can 383 be resolved into one or more URLs, one of the URLs is returned to 384 the browser which then transparently retrieves and displays the 385 intended content. 387 6. Handle resolution 389 Handle clients and handle services use the Handle Resolution 390 Protocol [5] to conduct resolution transactions. The Handle 391 Resolution protocol uses registered port number 2641. By 392 default, a handle resolution request will be answered with 393 all of the typed data associated with a handle, with the 394 exception of the administrative data. It is also possible 395 to request data only of a certain type. 397 Handle clients that do not know which handle service to 398 query for a given handle start with the Global Handle 399 Registry, which is guaranteed to know which service contains 400 a given handle. Within a given service, a client uses the hash 401 table specific to the service to discover the individual 402 server, or set of replicated servers, which can resolve the 403 given handle. 405 A number of handle resolution clients have been constructed, 406 all of which utilize the Handle Client Library [6], which 407 is currently implemented as a C library. The clients include 408 a Web proxy server, the Handle System Resolver [4], and the 409 Grail Web browser [7]. 411 7. Handle administration 413 Handle System administration is carried out using the 414 Handle System Administration Protocol [8]. This protocol 415 allows the creation and administration of handles and their 416 associated data within the Handle System. A series of APIs 417 currently under construction on top of this protocol will be 418 made publicly available. 420 8. Security Consideration 422 The Handle System has been designed to enable secure 423 transactions between clients and servers and to allow 424 secure and stable storage of handle data. Development and 425 documentation of secure practices and policies is underway. 427 A handle does not in itself pose a security threat. When 428 specified or used in URL context, it is subject to all 429 the security considerations in the URL specification [3]. 431 9. Handle System and URL/URN/URI 433 While the Handle System is designed to be usable in many 434 contexts and is not a subset or extension of current UR* schemes, 435 it can be used in conjunction with those schemes. When used 436 within those schemes it is, of course, subject to their 437 constraints. The Handle System is designed to provide all the 438 fundamental requirements outlined in the URN/URI specifications 439 [9,10]. On the other hand, the Handle System differs from the 440 current proposed URN implementations [11,12,13] discussed in the 441 IETF URN working group in the following ways. 443 First of all, the Handle System defines a namespace independent 444 of URI, and is not subject to the current namespace constraints 445 of URI. The namespace of handles is Unicode based, and imposes no 446 reserved or excluded characters on the handle string. This 447 allows handles to be specified in any national language natively 448 in a globally unique and unambiguous manner. The elimination of 449 any reserved characters also allows any legacy naming system, 450 such as SICI [14], to be used with no or minimum change. 452 The Handle System is designed to support, instead of exclude, the 453 use of user friendly names in any native language. There are 454 situations in which using descriptive names may hurt the persistence 455 of the name once the identified object changes its association. 456 Objects of this nature may be better served using non-descriptive 457 names; for example, digits only. On the other hand, there are 458 objects for which descriptive names are desirable. 460 The current URN/URI was defined "generally to be for machine, 461 rather than human, consumption" [20]. It uses a subset of ASCII 462 character set, and requires a set of reserved/excluded characters. 463 A Human Friendly Name Service is expected to work with it. 465 URN services may be used to resolve handles from the Handle System. 466 For example, the handle "cnri.dlib/july95-arms" may be specified as 467 "urn:hdl:cnri.dlib/july95-arms". This will allow any URN-aware 468 browsers to resolve the handle as a URN. Handles specified as an URN 469 must follow the URN syntax [13]. 471 10. History and Acknowledgment 473 The initial design and implementation of the Handle System was 474 part of the Computer Science Technical Reports project, funded by 475 the Defense Advanced Projects Agency (DARPA) under Grant No. 476 MDA-972-92-J-1029. One aspect of this project was to develop a 477 framework for the underlying infrastructure of digital libraries. 478 It is described in a paper by Robert Kahn and Robert Wilensky [15]. 479 The first implementation was created at CNRI in the fall of 1994. 480 Subsequent work on the Handle System has been supported in part 481 by the Advanced Research Projects Agency under Grant No. 482 MDA972-92-J-1029. 484 The following people have contributed to the Handle System design 485 and implementation: David Ely, William Arms, Navjeet Chabbewal, 486 Judith Grass, Robert Kahn, Timothy Kendall, Connie McLindon, 487 Charles Orth, Ed Overly, Varna Puvvada, John Stewart, Allison 488 Yu-McNamara, Ron Ely, Catherine Rey, Jane Euler, Larry Lannom, 489 and Sam Sun. We also want to acknowledge the contribution of the 490 other members of the Computer Science Technical Reports project. 492 11. Author's Address 494 Sam X. Sun 495 1895 Preston White Dr. 496 Suite 100 497 Reston, VA 20191-5434 498 (703) 620-8990 499 ssun@cnri.reston.va.us 501 12. References 503 [1] The Unicode Consortium, "The Unicode Standard, 504 Version 2.0", Addison-Wesley Developers Press, 1996. 505 ISBN 0-201-48345-9 507 [2] Yergeau, Francois, "UTF-8, A Transform Format for Unicode 508 and ISO10646", RFC2044, October 1996. 509 http://ds.internic.net/rfc/rfc2044.txt 511 [3] Berners-Lee, T., Masinter, L., McCahill, M., et al., 512 "Uniform Resource Locators (URL)", RFC1738, December 1994. 513 http://ds.internic.net/rfc/rfc1738.txt 515 [4] Handle System Resolver. 516 http://www.handle.net/resolver/ 518 [5] Handle System Client Library download site. 519 http://www.handle.net/download.html 521 [6] Handle Resolution Protocol. 522 http://www.handle.net/client_spec.html 524 [7] The Grail Internet Browser. 525 http://grail.cnri.reston.va.us/grail/ 527 [8] Handle Administration Protocol. 528 http://www.handle.net/handle_admin.html 530 [9] Sollins, K. and L. Masinter, "Functional Requirements 531 for Uniform Resource Names", RFC 1737, December 1994. 532 http://ds.internic.net/rfc/rfc1737.txt 534 [10] Berners-Lee, T., "Universal Resource Identifiers 535 in WWW" RFC 1630, June 1994. 536 http://ds.internic.net/rfc/rfc1630.txt 538 [11] Daniel, Ron and Michael Mealling, "Resolution of 539 Uniform Resource Identifiers using the Domain Name 540 System", RFC 2168, June 1997. 541 http://ds.internic.net/rfc/rfc2168.txt 543 [12] Daniel, Jr., Ron, "A Trivial Convention for using 544 HTTP in URN Resolution", RFC-2169, June 1997. 545 http://ds.internic.net/rfc/rfc2169.txt 547 [13] Moats, Ryan, "URN Syntax", RFC-2141, May 1997. 548 http://ds.internic.net/rfc/rfc2141.txt 550 [14] Serial Item and Contribution Identifier (SICI) Standard. 551 http://sunsite.berkeley.edu/SICI/ 553 [15] Kahn, Robert and Wilensky, Robert. "A Framework for 554 Distributed Digital Object Services", May, 1995. 555 http://www.cnri.reston.va.us/tmp_hp/k-w.html 557 [16] Digital Object Identifier System. 558 http://hdl.handle.net/10.1000/1 560 [17] National Digital Library Program. 561 http://hdl.handle.net/4263537/003 563 [18] The CNRI Registry. 564 http://hdl.handle.net/4263537/001 566 [19] Defense Virtual Library. 567 http://hdl.handle.net/4263537/002 569 [20] Sollins, K., "Architectural Principles of Uniform Resource 570 Name Resolution", September 26, 1997, Work in Progress. 571 ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-req-frame-04.txt 573 [21] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 574 Specifications: ABNF", RFC 2234, November 1997, 575 http://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txt 577 [22] T. Berners-Lee, L. Masinter, R. Fielding, "Uniform Resource 578 Identifiers (URI): Generic Syntax", work in progress, 579 June 1998, ftp://ftp.ietf.org/internet-drafts/draft-fielding- 580 uri-syntax-03.txt 582 [23] List of IANA registered charset names. 583 ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets 585 INTERNET-DRAFT 586 draft-ietf-handle-system-01.txt 587 Expires Jan 16, 1999