idnits 2.17.1 draft-ietf-urn-biblio-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 349 has weird spacing: '...the serial, 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NISO2' is mentioned on line 352, but not defined == Missing Reference: 'ISO 1' is mentioned on line 155, but not defined == Missing Reference: 'ISO 2' is mentioned on line 222, but not defined == Missing Reference: 'ISO 3' is mentioned on line 222, but not defined == Missing Reference: 'Appenidx D' is mentioned on line 352, but not defined == Unused Reference: 'ISO2' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'ISO3' is defined on line 382, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3' == Outdated reference: A later version (-05) exists of draft-ietf-urn-syntax-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'NISO 1' ** Downref: Normative reference to an Informational RFC: RFC 1737 (ref. 'NISO 2') Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Clifford Lynch 2 draft-ietf-urn-biblio-00.txt University of California 3 22 March 1997 Cecilia Preston 4 Expires in six months Preston & Lynch 5 Ron Daniel Jr. 6 Los Alamos National Laboratory 8 Using Existing Bibliographic Identifiers 9 as 10 Uniform Resource Names 12 Status of this Document 14 This document is an Internet-Draft. Internet-Drafts are 15 working documents of the Internet Engineering Task Force 16 (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced or made obsolete by 22 other documents at any time. It is inappropriate to use 23 Internet-Drafts as reference material or to cite them other 24 than as works in progress. 26 Distribution of this document is unlimited. Please send 27 comments to clifford.lynch@ucop.edu and cecilia@well.com. 29 This document does not specify a standard; it is purely 30 informational. 32 0. Abstract 34 A system for Uniform Resource Names (URNs) must be capable 35 of supporting identifiers from existing widely-used naming 36 systems. This document discusses how three major 37 bibliographic identifiers (the ISBN, ISSN and SICI) can be 38 supported within the URN framework and the currently 39 proposed syntax for URNs. 41 1. Introduction 43 The ongoing work of several IETF working groups, most 44 recently in the Uniform Resource Names working group, has 45 culminated the development of a syntax for Uniform Resource 46 Names (URNs). The functional requirements and overall 47 framework for Uniform Resource Names are specified in RFC 48 1737 [Sollins & Masinter] and the current proposal for the 49 URN syntax is draft-ietf-urn-syntax-04.txt [Moats]. 51 As part of the validation process for the development of 52 URNs the IETF working group has agreed that it is important 53 to demonstrate that the current URN syntax proposal can 54 accommodate existing identifiers from well managed 55 namespaces. One such well-established infrastructure for 56 assigning and managing names comes from the bibliographic 57 community. Bibliographic identifiers function as names for 58 objects that exist both in print and, increasingly, in 59 electronic formats. This Internet draft demonstrates the 60 feasibility of supporting three representative bibliographic 61 identifiers within the currently proposed URN framework and 62 syntax. 64 Note that this document does not purport to define the 65 "official" standard way of doing so; it merely demonstrates 66 feasibility. It has not been developed in consultation with 67 the standards bodies and maintenance agencies that oversee 68 the existing bibliographic identifiers. Any actual Internet 69 standard for encoding these bibliographic identifiers as 70 URNs will need to be developed in consultation with the 71 responsible standards bodies and maintenance agencies. 73 In addition, there are several open questions with regard to 74 the management and registry of Namespace Identifiers (NIDs) 75 for URNs. For purposes of illustration, we have used the 76 three NIDs "ISBN", "ISSN" and "SICI" for the three 77 corresponding bibliographic identifiers discussed in this 78 document. While we believe this to be the most appropriate 79 choice, it is not the only one. The NIDs could be based on 80 the standards body and standard number (e.g. "US-ANSI-NISO- 81 Z39.56-1997" rather than "SICI"). Alternatively, one could 82 lump all bibliographic identifiers into a single 83 "BIBLIOGRAPHIC" name space, and structure the namespace- 84 specific string to specify which identifier is being used. 85 We do not believe that these are advantageous approaches, 86 but must wait for the outcome of namespace management 87 discussions in the working group. 89 For the purposes of this document, we have selected three 90 major bibliographic identifiers (national and international) 91 to fit within the URN framework. These are the 92 International Standard Book Number (ISBN) [ISO1], the 93 International Standard Serials Number (ISSN) [NISO1,ISO2, 94 ISO3], and the Serial Item and Contribution Identifier 95 (SICI) [NISO2]. ISBNs are used to identify monographs 96 (books). ISSNs are used to identify serial publications 97 (journals, newspapers) as a whole. SICIs augment the ISSN 98 in order to identify individual issues of serial 99 publications, or components within those issues (such as an 100 individual article, or the table of contents of a given 101 issue). The ISBN and ISSN are defined in the United States 102 by standards issued by the National Information Standards 103 Organization (NISO) and also by parallel international 104 standards issued under the auspices of the International 105 Organization for Standardization (ISO). NISO is the ANSI- 106 accredited standards body serving libraries, publishers and 107 information services. The SICI code is defined by a NISO 108 document in the United States and does not have a parallel 109 international standards document at present. 111 Many other bibliographic identifiers are in common use (for 112 example, the CODEN, numbers assigned by major bibliographic 113 utilities such as OCLC and RLG, national library numbers 114 such as the Library of Congress Control Number) or are under 115 development. While we do not discuss them in this document, 116 many of these will also need to be supported within the URN 117 framework as it moves to large scale implementation. The 118 issues involved in supporting those additional identifiers 119 are anticipated to be broadly similar to those involved in 120 supporting ISBNs, ISSNs, and SICIs. 122 2. Identification vs. Resolution 124 It is important to distinguish between the resource 125 identified by a URN and the resources that can reasonably be 126 provided when attempting to resolve an identifier. For 127 example, the ISSN 0040-781X identifies the popular 128 "Time". All of it, every issue for from the start of 129 publication to present. Resolving such an identifier should 130 not result in the equivalent of hundreds of thousands of 131 pages of text and photos being dumped to the user's machine. 132 It is more reasonable for ISSNs to resolve to a navigational 133 system, such as an HTML-based search form, so the user may 134 select issues or articles of interest. ISBNs and SICIs, on 135 the other hand, do identify finite, manageably-sized 136 objects, but they may still be large enough that resolution 137 to a hierarchical system is appropriate. 139 In addition, the materials identified by an ISSN, ISBN or 140 SICI may exist only in printed or other physical form, not 141 electronically. The best that a resolver may be able to 142 offer is information about where to get the physical 143 resource, such as library holdings or a bookstore or 144 publisher order form. The URN Framework provides resolution 145 services that may be used to describe any differences 146 between the resource identified by a URN and the resource 147 that would be returned as a result of resolving that URN. 149 3. International Standard Book Numbers 151 3.1 Overview 153 An International Standard Book Number (ISBN) identifies an 154 edition of a monographic work. The ISBN is defined by the 155 standard NISO/ANSI/ISO 2108:1992 [ISO 1] 157 Basically, an ISBN is a ten-digit number (actually, the last 158 digit can be the letter "X" as well, as described below) 159 which is divided into four variable length parts usually 160 separated by hyphens when printed. The parts are as follows 161 (in this order): 163 * a group identifier which specifies a group of publishers, 164 based on national, geographic or some other criteria, 166 * the publisher identifier, 167 * the title identifier, 169 * and a modulus 11 check digit, using X in lieu of 10. 171 The group and publisher number assignments are managed in 172 such a way that the hyphens are not needed to parse the ISBN 173 unambiguously into its constituent parts. However, the ISBN 174 is normally transmitted and displayed with hyphens to make 175 it easy for human beings to recognize these parts without 176 having to make reference to or have knowledge of the number 177 assignments for group and publisher identifiers. 179 3.2 Encoding Considerations 181 Embedding ISBNs within the URN framework presents no 182 particular coding problems, since all of the characters that 183 can appear in an ISBN are valid in the identifier segment of 184 the URN. %-encoding is never needed. 186 Example: URN:ISBN:0-395-36341-1 188 For the ISBN namespace, some additional equivalence rules 189 are appropriate. Prior to comparing two ISBN URNs for 190 equivalence, it is appropriate to remove all hyphens, and to 191 convert any occurrences of the letter X to upper case. 193 3.3 Additional considerations 195 The ISBN standard and related community implementation 196 guidelines define when different versions of a work should 197 be assigned the same or differing ISBNs. In actuality, 198 however, practice varies somewhat depending on publisher as 199 to whether different ISBNs are assigned for paperbound vs. 200 hardbound versions of the same work, electronic vs. printed 201 versions of the same work, or versions of the same work 202 published for example in the US and in Europe. The choice 203 of whether to assign a new ISBN or to reuse an existing one 204 when publishing a revised printing of an existing edition of 205 a work or even a revised edition of a work is somewhat 206 subjective. Practice varies from publisher to publisher 207 (indeed, the distinction between a revised printing and a 208 new edition is itself somewhat subjective). The use of 209 ISBNs within the URN framework simply reflects these 210 existing practices. Note that it is likely that an ISBN URN 211 will often resolve to many instances of the work (many 212 URLs). 214 4. International Standard Serials Numbers 216 4.1 Overview 218 International Standard Serials Numbers (ISSN) identify a 219 work that is being published on a continued basis in issues; 220 they identify the entire (often open-ended, in the case of 221 an actively published) work. ISSNs are defined by the 222 standards ISO 3297:1986 [ISO 2] and ISO/DIS 3297 [ISO 3] and 223 within the United States by NISO Z39.9-1992 [NISO 1]. The 224 ISSN International Centre is located in Paris and 225 coordinates a network of regional centers. The National 226 Serials Data Program within the Library of Congress is the 227 US Center of this network. 229 ISSNs have the form NNNN-NNNN where N is a digit, the last 230 digit may be an upper case X as the result of the check 231 character calculation. Unlike the ISBN the ISSN components 232 do not have much structure; blocks of numbers are passed out 233 to the regional centers and publishers. 235 4.2 Encoding Considerations 237 Again, there is no problem representing ISSNs in the 238 namespace-specific string of URNs since all characters valid 239 in the ISSN are valid in the namespace-specific URN string, 240 and %-encoding is never required. 242 Example: URN:ISSN:1046-8188 244 Supplementary comparison rules are also appropriate for the 245 ISSN namespace. Just as for ISBNs, hyphens should be 246 dropped prior to comparison and occurrences of 'x' 247 normalized to uppercase. 249 4.3 Additional Considerations 251 The ISSN standard and related community implementation 252 guidelines specify when new ISSNs should be assigned vs. 253 continuing to use an existing one. There are some 254 publications where practice within the bibliographic 255 community varies from site to site, such as annuals or 256 annual conference proceedings. In some cases these are 257 treated as serials and ISSNs are used, and in some cases 258 they are treated as monographs and ISBNs are used. For 259 example SIGMOD Record volume 24 number 2 June 1995 contains 260 the Proceedings of the 1995 ACM SIGMOD International 261 Conference on Management of Data. If you subscribe to the 262 journal (ISSN 0163-5808) this is simply the June issue. On 263 the other hand you may have acquired this volume as the 264 conference proceedings (a monograph) and as such would use 265 the ISBN 0-89791-731-6 to identify the work. There are also 266 varying practices within the publishing community as to when 267 new ISSNs are assigned due to the change in the name of a 268 periodical (Atlantic becomes Atlantic Monthly); or when a 269 periodical is published both in printed and electronic 270 versions (The New York Times). The use of ISSNs as URNs 271 will reflect these judgments and practices. 273 5. Serial Item and Contribution Identifiers 275 5.1 Overview 277 The standard for Serial Item and Contribution Identifiers 278 (SICI) has recently been extensively revised and is defined 279 by NISO/ANSI Z39.56-1997 [NISO 2]. The maintenance agency 280 for the SICI code is the UnCover Corporation. 282 SICI codes can be used to identify an issue of a serial, or 283 a specific contribution (i.e., an article, or the table of 284 contents) within an issue of a serial. SICI codes are not 285 assigned, they are constructed based on information about 286 the issue or issue component in question. 288 The complete syntax for the SICI code will not be discussed 289 here; see NISO/ANSI Z39.56-1997 for details. However an 290 example and brief review of the major components is needed 291 to understand the relationship with the ISSN and how this 292 identifier differs. An example of a SICI code is: 294 0015-6914(19960101)157:1<62:KTSW>2.0.TX;2-F 296 The first nine characters are the ISSN identifying the 297 serial title. The second component, in parentheses, is the 298 chronology information giving the date the particular serial 299 issue was published. In this example that date was January 300 1, 1996. The third component, 157:1, is enumeration 301 information (volume, number) on the particular issue of the 302 serial. These three components comprise the "item segment" 303 of a SICI code. By augmenting the ISSN with the chronology 304 and/or enumeration information, specific issues of the 305 serial can be identified. The next segment, <62:KTSW>, 306 identifies a particular contribution within the issue. In 307 this example we provide the starting page number and a title 308 code constructed from the initial characters of the title. 309 Identifiers assigned to a contribution can be used in the 310 contribution segment if page numbers are inappropriate. The 311 rest of the identifier is the control segment, which 312 includes a check character. Interested readers are 313 encouraged to consult the standard for an explanation of the 314 fields in that segment. 316 5.2 Encoding Considerations 318 The character set for SICIs is intended to be email- 319 transport-transparent, so it does not present major 320 problems. However, all printable excluded and reserved 321 characters from the URN syntax draft are valid in the SICI 322 character set and must be %-encoded. 324 Example of a SICI for an issue of a journal 326 URN:SICI:1046-8188(199501)13:1%3C%3E1.0.TX;2-F 328 For an article contained within that issue 330 URN:SICI:1046-8188(199501)13:1%3C69:FTTHBI%3E2.0.TX;2-4 332 Special equivalence rules for SICIs are not appropriate for 333 definition as part of the namespace and incorporation in 334 areas such as cache management algorithms. These are best 335 left to resolver systems which try to determine if two SICIs 336 refer to the same content. Consequently, we do not propose 337 any specific rules for equivalence testing through lexical 338 manipulation. 340 5.3 Additional Considerations 342 Since the serial is identified by an ISSN, some of the 343 ambiguity currently found in the assignment of ISSNs carries 344 over into SICI codes. In cases where an ISSN may refer to a 345 serial that exists in multiple formats, the SICI contains a 346 qualifier that specifies the format type (for example, 347 print, microform, or electronic). SICI codes may be 348 constructed from a variety of sources (the actual issue of 349 the serial, a citation or a record from an abstracting 350 service) and, as such are based on the principle of using 351 all available information, so there may be multiple SICI 352 codes representing the same article [NISO2, Appenidx D]. 353 For example, one code might be constructed with access to 354 both chronology and enumeration (that is, date of issue and 355 volume, issue and page number), another code might be 356 constructed based only on enumeration information and 357 without benefit of chronology. Systems that use SICI codes 358 employ complex matching algorithms to try to match SICI 359 codes constructed from incomplete information to SICI codes 360 constructed with the benefit of all relevant information. 362 6. Security Considerations 364 This document proposes means of encoding several existing 365 bibliographic identifiers within the URN framework. It does 366 not discuss resolution; thus questions of secure or 367 authenticated resolution mechanisms are out of scope. It 368 does not address means of validating the integrity or 369 authenticating the source or provenance of URNs that contain 370 bibliographic identifiers. Issues regarding intellectual 371 property rights associated with objects identified by the 372 various bibliographic identifiers are also beyond the scope 373 of this document, as are questions about rights to the 374 databases that might be used to construct resolvers. 376 7. References 378 [ISO1] NISO/ANSI/ISO 2108:1992 Information and documentation 379 -- International standard book number (ISBN) 380 [ISO2] ISO 3297:1986 Documentation -- International standard 381 serial numbering (ISSN) 382 [ISO3] ISO/DIS 3297 Information and documentation -- 383 International standard serial numbering (ISSN) 384 (Revision of ISO 3297:1986) 385 [Moats] R. Moats, "URN Syntax" draft-ietf-urn-syntax- 386 04.text. March 1997 387 [NISO 1] NISO/ANSI Z39.9-1992 International standard serial 388 numbering (ISSN) 389 [NISO 2] NISO/ANSI Z39.56-1997 Serial Item and Contribution 390 Identifier 391 [Sollins & Masinter] K. Sollins and L. Masinter, "Functional 392 Requirements for Uniform Resource Names", RFC 1737 393 December 1994. 395 8. Author's Addresses 397 Clifford Lynch 398 University of California Office of the President 399 300 Lakeside Drive, 8th floor 400 Oakland CA 94612-3550 401 clifford.lynch@ucop.edu 403 Cecilia Preston 404 Preston & Lynch 405 PO Box 8310 406 Emeryville, CA 94662 407 cecilia@well.com 409 Ron Daniel Jr. 410 Advanced Computing Lab, MS B287 411 Los Alamos National Laboratory 412 Los Alamos, NM, 87545 413 voice: +1 505 665 0597 414 fax: +1 505 665 4939 415 http://www.acl.lanl.gov/~rdaniel