idnits 2.17.1 draft-hakala-sici-00.txt: -(58): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 647 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 1 character in excess of 72. ** The abstract seems to contain references ([Lynch], [Moats]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (28 August 2001) is 8276 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'NISO2' is mentioned on line 474, but not defined ** Obsolete normative reference: RFC 2141 (ref. 'Moats') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3044 (ref. 'Rozenfeld') (Obsoleted by RFC 8254) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Juha Hakala 2 Internet-Draft Helsinki University Library 3 Category: Informational 28 August 2001 4 draft-hakala-sici-00.txt 5 Expires: 28 February 2002 7 Using Serial Item and Contribution Identifiers as 8 Uniform Resource Names 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on 28 February 2002. 32 Abstract 34 This document discusses how Serial Item and Contribution Identifiers 35 (SICIs; persistent and unique identifiers for serial issues and 36 contributions such as articles) can be supported within the URN 37 framework and the syntax for URNs defined in RFC 2141 [Moats]. Much of 38 the discussion below is based on the ideas expressed in RFC 2288 39 [Lynch]. Chapter 5 contains a URN namespace registration request 40 modelled according to the template in RFC 2611 [Daigle et al.]. 42 1. Introduction 44 As part of the validation process for the development of URNs the IETF 45 working group agreed that it is important to demonstrate that the 46 current URN syntax proposal can accommodate existing identifiers from 47 well-established namespaces. One such infrastructure for assigning and 48 managing names comes from the bibliographic community. Bibliographic 49 identifiers function as names for objects that exist both in print and, 50 increasingly, in electronic formats. RFC 2288 [Lynch et. al.] 51 investigated the feasibility of using three identifiers (ISBN, ISSN and 52 SICI) as URNs. 54 SICI is an American national standard defined by NISO/ANSI Z39.56-1996 55 [NISO]. The need to develop a new version of the standard is at present 56 being investigated by NISO. 58 RFC 2288 does not � and it was not the aim of its authors � to analyse 59 how SICI-based URNs can actually be resolved. This text will specify one 60 solution to this question. There may be other, complementary resolution 61 services. 63 Generally, the difficulty of designing a URN resolution service is 64 dependent on two factors: 66 * Is the identifier dumb, or does it provide a hint on where to find a 67 resolution service? 69 * How many potential resolution services are there? 71 ISBN (International Standard Book Number) is a good example of an 72 intelligent identifier. Analysis of the ISBN will reveal not only the 73 region where the ISBN has been assigned, but also the publisher who is 74 responsible for the book. Resolution of ISBN-based URNs can be 75 decentralised to national bibliography databases, maintained by the 76 national libraries. If the ISBN was a dumb identifier, this would be 77 impossible. 79 International Standard Serial Number (ISSN) is a dumb identifier. It 80 does not have a publisher identifier; serials published by a certain 81 company get seemingly random ISSNs. Although ISSNs are allocated to 82 regional agencies in blocks, which gives the system some "intelligence", 83 a resolution service should not rely on these blocks, but use the global 84 ISSN database. It contains a bibliographic description of every 85 periodical that has received an ISSN. Thus, it is easy to resolve ISSN- 86 based URNs even though the identifier itself does not help in localising 87 the resolution service. 89 SICI is based on ISSN (see below for a description of its syntax). Like 90 ISSN, it is therefore a dumb identifier. But there is not, and will 91 never be, a global SICI database, which would contain bibliographic 92 information about every serial issue and/or article published in the 93 world. Most articles will not be catalogued at all, and the existing 94 bibliographic information about articles is dispersed into a large 95 number of databases maintained by publishers, libraries and other 96 information intermediaries. Although it might be technically possible to 97 merge records from these databases into a union catalogue, in practice 98 such an enterprise is not politically possible. 100 As a "dumb" identifier with a large and ever growing number of potential 101 resolution services SICI poses interesting challenges to the design of 102 the URN resolution process. 104 Generally, a combination of dumb identifier and multiple resolution 105 services is a problem, since there is no simple way of finding out which 106 resolution service is the correct one. A gateway service is needed for 107 providing this valuable information. Below we propose that for SICI- 108 based URNs, the global ISSN database will be capable of acting as a link 109 between the user and the resolution service. 111 The registration request for acquiring a Namespace Identifier (NID) 112 "SICI" for Serial Item and Contribution Identifiers has been written by 113 the National Library of Finland on behalf of the National Information 114 Standards Organization (NISO). The request is included in chapter 5 of 115 this text. 117 The document at hand is part of a global co-operation of the national 118 libraries to foster identification of electronic documents in general 119 and utilisation of URNs in particular. This work is co-ordinated by a 120 working group established by the Conference of Directors of National 121 Libraries (CDNL). 123 We have used the URN Namespace Identifier "SICI" for the Serial Item and 124 Contribution Identifiers in examples below. 126 2. Identification vs. Resolution 128 As a rule the SICIs identify finite, manageably-sized objects, but these 129 objects may still be large enough so that resolution to a hierarchical 130 system, such as all articles published in a serial issue, is 131 appropriate. 133 The materials identified by a SICI may exist only in printed or other 134 physical form, not electronically. The best that a resolver service will 135 be able to offer in this case is bibliographic data from the database 136 providing resolution services, including information about where the 137 physical resource is stored in the owner institution's holdings. 139 3. Serial Item and Contribution Identifier 141 3.1 Overview 143 The Serial Item and Contribution Identifier (SICI) standard defines a 144 variable length code that provides unique identification of serial items 145 (e.g., issues) and the contributions (e.g., articles) contained in a 146 serial title. SICI is specified in NISO/ANSI Z39.56-1996 [NISO2]. Like 147 other NISO standards, the SICI document is available for free in the Web. 149 SICI is based on ISSN (International Standard Serial Number), but 150 augments it extensively. SICI is a combination of three segments, all of 151 which are required: 153 Item segment; the data elements needed to describe the serial item such 154 as serial issue (ISSN, Chronology, Enumeration) 156 Contribution segment, the data elements needed to identify contributions 157 within an item (Location, Title Code) 159 Control segment, the data elements needed to record those administrative 160 elements that determine the validity, version, and format of the SICI 161 code representation. 163 RFC 2288 provides the following example: 165 0015-6914(19960101)157:1<62:KTSW>2.0.TX;2-F 167 The first nine characters are the ISSN identifying the serial title. 168 The second component, in parentheses, is the chronology information 169 giving the date the particular serial issue was published. In this 170 example that date was January 1, 1996. The third component, 157:1, 171 is enumeration information (volume, number) for the particular issue 172 of the serial. These three components comprise the "item segment" of 173 a SICI code. By augmenting the ISSN with the chronology and/or 174 enumeration information, specific issues of the serial can be 175 identified. The next segment, <62:KTSW>, identifies a particular 176 contribution within the issue. In this example we provide the 177 starting page number and a title code constructed from the initial 178 characters of the title. Identifiers assigned to a contribution can 179 be used in the contribution segment if page numbers are 180 inappropriate. The rest of the identifier is the control segment, 181 which includes a check character. Interested readers are encouraged 182 to consult the standard for an explanation of the fields in that 183 segment. 185 SICI can be seen as a logical extension of the ISSN to the items and 186 individual contributions that make up a serial's hierarchical structure. 187 The current version of the SICI does have some limitations; it does not 188 allow identification of subsections of an article such as paragraphs or 189 diagrams. If deemed necessary, the functionality needed for article 190 subsection identification could be added to the standard. 192 The current version of SICI guarantees uniqueness in most situations; 193 however, the standard does not always differentiate between multiple 194 variant formats in which an electronic article may be published. For 195 instance, variants of a digitised article published in PDF and HTML 196 formats will receive the same SICI, provided that the ISSN is the same. 198 According to the rules of the ISSN centre, ISSN numbers can be applied 199 retrospectively to old periodicals. If the original printed document has 200 an ISSN, the same identifier is also valid for the digitised version. 201 ISSN guidelines formulate this principle in the following way: 203 A reproduction is a copy of an item and intended to function as a 204 substitute for that item. The reproduction may be in a different medium 205 from the original but it is not a different edition in itself. The ISSN 206 assigned to the original is valid for the reproduction, a new ISSN is not 207 assigned to the reproduction. 209 ISSN numbers are assigned by regional agencies, which receive ISSN 210 blocks from the ISSN International Centre. SICI usage is not dependent 211 on such formal agencies; the aim is that once ISSN is known, SICI codes 212 can be created, manually or by computer program, by publishers, 213 libraries, document delivery services or even by individual users. 215 Given the complexity of SICI codes, the recommended practice is to 216 automate the SICI creation process. If an article is structured enough, 217 all elements of SICI can be extracted from the document. A tool capable 218 of this has been built by the E.U. project DIEPER; this tool, of course, 219 only works properly if the document is structured in the way the DIEPER 220 project recommends. Another, less challenging option is a SICI 221 generator, which builds syntactically correct SICIs including the check 222 character if the basic ingredients are typed in manually. 224 3.2 Encoding Considerations and Lexical Equivalence 226 RFC 2288 contains the following simple and yet sufficient analysis of 227 SICI encoding: 229 The character set for SICIs is intended to be email-transport- 230 transparent, so it does not present major problems. However, all 231 printable excluded and reserved characters from the URN syntax are 232 valid in the SICI character set and must be %-encoded. 234 Example of a SICI for an issue of a journal: 236 URN:SICI:1046-8188(199501)13:1%3C%3E1.0.TX;2-F 238 For an article contained within that issue: 240 URN:SICI:1046-8188(199501)13:1%3C69:FTTHBI%3E2.0.TX;2-4 242 Equivalence rules for SICIs are not appropriate for definition as 243 part of the namespace and incorporation in areas such as cache 244 management algorithms. It is best left to resolver systems which try 245 to determine if two SICIs refer to the same content. Consequently, 246 we do not propose any specific rules for equivalence testing through 247 lexical manipulation. 249 3.3 Resolution of SICI-based URNs 251 Since ISSN is a dumb code, SICI does not contain any explicit hint on 252 where to find the URN resolution service or services. However, an 253 efficient and global resolution service can be accomplished by using the 254 ISSN register as a way station. In spring 2001, the ISSN register 255 contained about one million bibliographic records describing serials, 256 including thousands of electronic journals. There are several other 257 databases, which contain hundreds of thousands of serial records, but 258 the ISSN register has the best coverage. 260 The first step in resolving a SICI-based URN is a query to the ISSN 261 register. The SICI resolution service in the ISSN register will parse 262 the SICI code in order to extract the ISSN from it. 264 ISSN will then be used as a search key for retrieving the bibliographic 265 record of the serial from the ISSN register. 267 Currently the ISSN register already contains thousands of records 268 describing electronic journals. These records contain the URL of the 269 serial's home page. 271 This URL is appropriate for resolving the URN based on the ISSN of the 272 periodical. The mechanism for resolving such URNs via the ISSN register 273 has been specified in RFC 3044 [Rozenfeld]. The ISSN International 274 Centre has already built a demonstration URN resolution service for 275 ISSN-based URNs into their present information system. 277 In order to resolve SICI-based URNs, a new data element has to be added 278 into the records in the ISSN register. This data element would contain 279 the network address (URL) of the database, which holds the article 280 required and/or bibliographic information about it. It must also be 281 possible to specify volumes and if necessary issues which are included 282 in the database within this data element. The data element should be 283 repeatable, since the same article may be available from multiple 284 sources. For instance, the publisher, Library of Congress 285 (http://www.loc.gov/), JSTOR (http://www.jstor.org/) and a number of 286 host services such as EBSCO (http://www.ebsco.com/home/) may all have a 287 copy of the same resource. 289 The SICI resolution service built into the ISSN register will check if 290 database address information is available in the bibliographic record of 291 the serial. Then it makes sure that the volume and/or issue needed is 292 available via the service. If this is the case, the application will 293 make the query, receive the result � article or bibliographic 294 information about it - and pass it on to the user. 296 The functionality described above was implemented in co-operation 297 between the ISSN International Centre and the E.U. project DIEPER 298 (http://gdz.sub.uni-goettingen.de/dieper/). The SICI resolution service 299 is an extension of the service built for resolving ISSN-based URNs. By 300 March 2001 a demonstrator service via which several of the databases 301 maintained by the project partners could be accessed was released for 302 internal use within the project. The ISSN IC and project partners wish 303 to maintain the service also after the formal end of the project. 305 Discussions about adding the new data element into bibliographic records 306 in the ISSN register are under way. 308 Please note that the discussion herein applies to SICIs assigned to 309 serial contributions. Since serial items (issues) have seldom been 310 described or digitised as such, a search by serial item SICI will in 311 practice be expanded into retrieval of all contributions (articles) 312 within the serial item (issue) in question. 314 If a resolution service for the resource at hand does not exist, or the 315 user is not authorised to utilise it, he/she may get the bibliographic 316 description of the serial from the ISSN register. 318 3.4 Additional considerations 320 Electronic journals have rapidly become very popular in scientific 321 publishing. The main reasons for this are the emergence of viable 322 business models (e.g. licensing) and the birth of a reliable and 323 efficient delivery mechanism (the Web). 325 New content is being added via two different channels. A significant 326 number of scientific journals is published in electronic form, usually 327 alongside a printed version. On the other hand, old printed volumes are 328 digitised and made available in electronic form. Digitisation is done by 329 development projects such as DIEPER, established services such as JSTOR, 330 or publishers - for instance Elsevier is digitising all printed journals 331 the company has published. 333 Reliable linking of articles to references and bibliographic data about 334 the articles is an important issue. URLs are as of this writing the most 335 common means used for linking, but their reliability is low; average 336 lifetime for a URL is estimated to be two years. 338 A more reliable linking mechanism than URLs is urgently needed. Many 339 scientific publishers are already using Digital Object Identifiers (DOI) 340 for their materials. DOI resolution service is based on Handle system, 341 which is "a comprehensive system for assigning, managing, and resolving 342 persistent identifiers, known as "handles," for digital objects and 343 other resources on the Internet" (see 344 http://www.handle.net/introduction.html). Handles can be used as Uniform 345 Resource Names(URNs). 347 URN is both an identifier and a non-commercial and technically advanced 348 resolution service. Due to the co-operation of the ISSN International 349 Centre the URN resolution service for articles outlined in this Internet 350 standard is global, and can accommodate an unlimited number of article 351 services located anywhere in the world. 353 For instance, in order to establish URN-based links to articles 354 digitised in JSTOR service, a number of steps are necessary. First, each 355 article must be identified by SICI, and these SICIs must be indexed in 356 the JSTOR database. Second, bibliographic records of JSTOR journals in 357 the ISSN register must all be enriched with a link to the JSTOR search 358 interface and volume/issue information. For instance, the bibliographic 359 record describing the journal "Ecology" must contain the information 360 that volumes 1-77 (1920-1996) are available via JSTOR. This information 361 may be quite volatile, and maintenance of the ISSN register must 362 therefore be frequent and efficient. 364 Apart from modification of the data, some programming work is needed. 365 Due to the work done in the DIEPER project, the ISSN register already 366 has the functionality needed for resolving SICI-based URNs. Adding the 367 required functionality into the JSTOR database may or may not be 368 difficult depending on the system architecture; in DIEPER some partners 369 were able to implement the required functionality quite easily. 371 Since the Web browsers do not support URN resolution yet, the final step 372 in enabling resolution of URN-based SICIs is installation of the browser 373 plug-in developed by the ISSN International Centre. 375 For various reasons, one article may be available in several locations. 376 Every article copy may have a different set of users who are allowed 377 access to it. For instance, a copy acquired by a national library via 378 legal deposit may only be available within the library premises. 380 Making the links context sensitive � provide only those links that 381 "work" for a user is a challenge. OpenURL framework [Van de Sompel] 382 provides a means for sensitive linking. As of this writing OpenURL is 383 rapidly gaining popularity, and there are already a few integrated 384 library systems which support it. The ISSN register may in the future 385 support OpenURL usage; this would be very valuable when the same 386 resource (article) is available from several sources, which have 387 different user population. 389 In their present form the URN resolution services provided via the ISSN 390 register suit those services best, which are available in public domain, 391 and are reasonably stable. Numerous digitisation projects such as DIEPER 392 are currently making printed articles available in the Web in digital 393 form. 395 An additional benefit of coding the needed location and volume 396 information into the ISSN register would be that this database then 397 could also serve as a global registry of serial digitisation efforts. 398 Such a register is badly needed to avoid duplicate work. 400 Since the number of SICI resolution services will eventually be high, 401 the capacity of the server on which the ISSN register runs and its 402 network connection may become a bottleneck, especially if the articles 403 were delivered via the ISSN server to the users. Setting up mirror sites 404 would in this case be the most efficient means for load control and 405 balancing. Technically the setting up of mirror sites is not difficult. 406 The ISSN register contains approximately a million bibliographic 407 records, and is therefore not a very large database. 409 4. Security Considerations 411 This document proposes means of encoding and using Serial Item and 412 Contribution Identifiers within the URN framework. This document does 413 not discuss resolution except at a generic level; thus questions of 414 secure or authenticated resolution mechanisms in the ISSN register or in 415 actual resolution services are out of scope. This text does not address 416 means of validating the integrity or authenticating the source or 417 provenance of URNs that contain SICIs. Issues regarding intellectual 418 property rights associated with objects identified by the various 419 bibliographic identifiers are also beyond the scope of this document, as 420 are questions about rights to the databases that might be used to 421 construct resolvers. 423 5. Namespace registration 425 URN Namespace ID Registration for the Serial Item and Contribution 426 Identifier (SICI) 428 Namespace ID: 430 SICI 432 SICI is a well-established acronym for Serial Item and Contribution 433 Identifiers; giving this NID for any other system would cause a lot of 434 confusion. 436 This namespace ID has already been used in SICI-based URNs in the E.U. 437 project DIEPER. 439 Registration Information: 441 Version: 1 442 Date: 2001-08-28 444 Declared registrant of the namespace: 446 Name: Patricia Harris 447 E-mail: pharris@niso.org 448 Affiliation: National Information Standards Organisation 449 Address: 4733 Bethesda Avenue, Suite 300, Bethesda, MD 20814 451 Declaration of syntactic structure: 453 Each SICI contains three segments: 455 Item segment; the data elements needed to describe the serial item such 456 as serial issue (ISSN, Chronology, Enumeration) 458 Contribution segment, the data elements needed to identify contributions 459 within an item (Location, Title Code) 461 Control segment, the data elements needed to record those administrative 462 elements that determine the validity, version, and format of the SICI 463 code representation. 465 Example: 467 0015-6914(19960101)157:1<62:KTSW>2.0.TX;2-F 469 SICI codes can be generated and parsed by computer programs. 471 Relevant ancillary documentation: 473 SICI is an American national standard defined by NISO/ANSI Z39.56-1996 474 [NISO2]. A new version of the standard is currently under development. 476 Identifier uniqueness considerations: 478 SICI codes will almost always be unique. Since SICI is based on ISSN, 479 articles from different journals will definitely never get the same 480 SICI. Since enumeration and chronology information must also be given, 481 articles and other contributions published in different volumes and 482 issues will also never get the same SICI. 484 SICIs may not be unique if and only if: 486 If two or more contributions are published on the same page(s) and if 487 they have similar enough titles (the first letter of each word is the 488 same). 490 In a single issue of an electronic journal (which lacks page numbers) 491 there are two or more contributions with titles similar enough. 493 If there are several technical variants of an electronic serial 494 contribution (multiple formats, multiple resolutions) the current 495 version of SICI will not make any difference between these variants. In 496 this case the intellectual content will usually be the same, but layout 497 will differ from one version to another. 499 The new version of the SICI standard will be enhanced in order to 500 diminish the risk of non-unique SICIs. 502 Identifier persistence considerations: 504 Once assigned, SICI will never change. The same SICI will not be used 505 again for other serial items and contributions. 507 Process of identifier assignment: 509 There will not be a national, regional or international agency governing 510 the SICI assignment process. Publishers, libraries or other information 511 intermediaries will create SICIs when needed. The most important 512 prerequisite is that the journal must have an ISSN. 514 Although SICI assignment is decentralised, the national ISSN agencies 515 and the ISSN International Centre may support publishers and other 516 interested parties in SICI implementation. 518 SICI can - and should - be built via automated means. If the source 519 document such as article is sufficiently structured, SICI can be 520 generated without human involvement. Another option is a semi-automated 521 process, in which a human user types in the relevant data elements, and 522 the application takes care of building the code. 524 Process for identifier resolution: 526 Resolution will take place in two steps as defined in chapter 3.3. First 527 the ISSN register is used for finding the location of the resolution 528 service(s) for the serial and volume at hand. Using the linking 529 information stored in the serial's bibliographic record, the correct 530 resolution service is contacted, and the requested resource is delivered 531 to the user. 533 Rules for Lexical Equivalence: 535 We do not propose any specific rules for equivalence testing through 536 lexical manipulation. 538 Conformance with URN Syntax: 540 According to the RFC 2288: 542 The character set for SICIs is intended to be email-transport- 543 transparent, so it does not present major problems. However, all 544 printable excluded and reserved characters from the URN syntax are 545 valid in the SICI character set and must be %-encoded. 547 Example of a SICI for an issue of a journal: 549 URN:SICI:1046-8188(199501)13:1%3C%3E1.0.TX;2-F 551 For an article contained within that issue: 553 URN:SICI:1046-8188(199501)13:1%3C69:FTTHBI%3E2.0.TX;2-4 555 Validation mechanism: 557 Validity of a SICI string can be checked by modulus 37 check digit. 559 Scope: 561 Global. 563 6. References 565 [Daigle et al.]: Daigle, L., van Gulik, D., Iannella, R. & Faltstrom, 566 P.: URN Namespace Definition Mechanisms, RFC2611, June 1999. 568 [Lynch] Lynch, C., Using Existing Bibliographic Identifiers as Uniform 569 Resource Names, RFC 2288, February 1998 571 [Moats] Moats, R., URN Syntax, RFC 2141, May 1997. 573 [NISO] NISO/ANSI Z39.56-1996 Serial Item and Contribution Identifier. 574 Electronic resource, available at http://www.techstreet.com/cgi- 575 bin/pdf/free/152629/z39-56.pdf 577 [Rozenfeld] Rozenfeld, S., Using The ISSN (International Serial Standard 578 Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace, 579 RFC 3044, January 2001. 581 [Van de Sompel] Van de Sompel, Herbert & Beit-Arie, Oren: Open Linking 582 in the Scholarly Information Environment Using the OpenURL Framework. D- 583 Lib Magazine, March 2001. Electronic resource, available at 584 http://www.dlib.org/dlib/march01/vandesompel/03vandesompel.html 586 7. Authors' Address 588 Juha Hakala 589 Helsinki University Library - The National Library of Finland 590 P.O. Box 26 591 FIN-00014 Helsinki University 592 FINLAND 594 E-mail: juha.hakala@helsinki.fi 596 8. Full Copyright Statement 598 Copyright (C) The Internet Society (2001). All Rights Reserved. 600 This document and translations of it may be copied and furnished to 601 others, and derivative works that comment on or otherwise explain it 602 or assist in its implementation may be prepared, copied, published 603 and distributed, in whole or in part, without restriction of any 604 kind, provided that the above copyright notice and this paragraph are 605 included on all such copies and derivative works. However, this 606 document itself may not be modified in any way, such as by removing 607 the copyright notice or references to the Internet Society or other 608 Internet organizations, except as needed for the purpose of 609 developing Internet standards in which case the procedures for 610 copyrights defined in the Internet Standards process must be 611 followed, or as required to translate it into languages other than 612 English. 614 The limited permissions granted above are perpetual and will not be 615 revoked by the Internet Society or its successors or assigns. 617 This document and the information contained herein is provided on an 618 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 619 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 620 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 621 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 622 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.