idnits 2.17.1 draft-ietf-urn-biblio-01.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-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 -- 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 11 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. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 348 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: 'NISO1' is mentioned on line 225, but not defined == Missing Reference: 'NISO2' is mentioned on line 351, but not defined == Missing Reference: 'MOATS' is mentioned on line 183, but not defined == Missing Reference: 'Appenidx D' is mentioned on line 351, but not defined == Unused Reference: 'NISO 1' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'NISO 2' is defined on line 393, 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' ** Obsolete normative reference: RFC 2141 (ref. 'Moats') (Obsoleted by RFC 8141) -- Possible downref: Non-RFC (?) normative reference: ref. 'NISO 1' ** Downref: Normative reference to an Informational RFC: RFC 1737 (ref. 'NISO 2') Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Clifford Lynch 2 September 8. 1997 Coalition for Networked Information 3 draft-ietf-urn-biblio-01.txt Cecilia Preston 4 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. 28 This document does not specify a standard; it is purely 29 informational. 31 0. Abstract 33 A system for Uniform Resource Names (URNs) must be capable 34 of supporting identifiers from existing widely-used naming 35 systems. This document discusses how three major 36 bibliographic identifiers (the ISBN, ISSN and SICI) can be 37 supported within the URN framework and the currently 38 proposed syntax for URNs. 40 1. Introduction 42 The ongoing work of several IETF working groups, most 43 recently in the Uniform Resource Names working group, has 44 culminated the development of a syntax for Uniform Resource 45 Names (URNs). The functional requirements and overall 46 framework for Uniform Resource Names are specified in RFC 47 1737 [Sollins & Masinter] and the specification for the 48 URN syntax is RFC 2141 [Moats]. 50 As part of the validation process for the development of 51 URNs the IETF working group has agreed that it is important 52 to demonstrate that the current URN syntax proposal can 53 accommodate existing identifiers from well established 54 namespaces. One such infrastructure for assigning and 55 managing names comes from the bibliographic community. 56 Bibliographic identifiers function as names for objects that 57 exist both in print and, increasingly, in electronic formats. 58 This Internet draft demonstrates the feasibility of 59 supporting three representative bibliographic identifiers 60 within the currently proposed URN framework and syntax. 62 Note that this document does not purport to define the 63 "official" standard way ofmoving these bibliographic 64 identifiers into URNs; it merely demonstrates feasibility. 65 It has not been developed in consultation with these 66 standards bodies and maintenance agencies that oversee the 67 existing bibliographic identifiers. Any actual Internet 68 standard for encoding these bibliographic identifiers as 69 URNs will need to be developed in consultation with the 70 responsible standards bodies and maintenance agencies. 72 In addition, there are several open questions with regard to 73 the management and registry of Namespace Identifiers (NIDs) 74 for URNs. For purposes of illustration, we have used the 75 three NIDs "ISBN", "ISSN" and "SICI" for the three 76 corresponding bibliographic identifiers discussed in this 77 document. While we believe this to be the most appropriate 78 choice, it is not the only one. The NIDs could be based on 79 the standards body and standard number (e.g. "US-ANSI-NISO- 80 Z39.56-1997" rather than "SICI"). Alternatively, one could 81 lump all bibliographic identifiers into a single 82 "BIBLIOGRAPHIC" name space, and structure the namespace- 83 specific string to specify which identifier is being used. 84 Any final resolution of this must wait for the outcome of 85 namespace management discussions in the working group and 86 the broader IETF community. 88 For the purposes of this document, we have selected three 89 major bibliographic identifiers (national and international) 90 to fit within the URN framework. These are the International 91 Standard Book Number (ISBN) [ISO1], the International 92 Standard Serials Number (ISSN) [NISO1,ISO2, ISO3], and the 93 Serial Item and Contribution Identifier (SICI) [NISO2]. An 94 ISBN is used to identify a monograph (book). An ISSN is used 95 to identify serial publications (journals, newspapers) as a 96 whole. A SICI augments the ISSN in order to identify 97 individual issues of serial publications, or components 98 within those issues (such as an individual article, or the 99 table of contents of a given issue). The ISBN and ISSN are 100 defined in the United States by standards issued by the 101 National Information Standards Organization (NISO) and also 102 by parallel international standards issued under the auspices 103 of the International Organization for Standardization (ISO). 104 NISO is the ANSI-accredited standards body serving libraries, 105 publishers and information services. The SICI code is 106 defined by a NISO document in the United States and does not 107 have a parallel international standards document at present. 109 Many other bibliographic identifiers are in common use (for 110 example, CODEN, numbers assigned by major bibliographic 111 utilities such as OCLC and RLG, national library numbers such 112 as the Library of Congress Control Number) or are under 113 development. While we do not discuss them in this document, 114 many of these will also need to be supported within the URN 115 framework as it moves to large scale implementation. The 116 issues involved in supporting those additional identifiers 117 are anticipated to be broadly similar to those involved in 118 supporting ISBNs, ISSNs, and SICIs. 120 2. Identification vs. Resolution 122 It is important to distinguish between the resource 123 identified by a URN and the resources a URN resolver that can 124 reasonably return when attempting to resolve an identifier. 125 For example, the ISSN 0040-781X identifies the popular 126 magazine "Time" -- all of it, every issue for from the start 127 of publication to present. Resolving such an identifier 128 should not result in the equivalent of hundreds of thousands 129 of pages of text and photos being dumped to the user's 130 machine. It is more reasonable for ISSNs to resolve to a 131 navigational system, such as an HTML-based search form, so 132 the user may select issues or articles of interest. ISBNs 133 and SICIs, on the other hand, do identify finite, manageably- 134 sized objects, but these objects may still be large enough 135 that resolution to a hierarchical system is appropriate. 137 In addition, the materials identified by an ISSN, ISBN or 138 SICI may exist only in printed or other physical form, not 139 electronically. The best that a resolver may be able to 140 offer is information about where to get the physical 141 resource, such as library holdings or a bookstore or 142 publisher order form. The URN Framework provides resolution 143 services that may be used to describe any differences 144 between the resource identified by a URN and the resource 145 that would be returned as a result of resolving that URN. 147 3. International Standard Book Numbers 149 3.1 Overview 151 An International Standard Book Number (ISBN) identifies an 152 edition of a monographic work. The ISBN is defined by the 153 standard NISO/ANSI/ISO 2108:1992 [ISO1] 155 Basically, an ISBN is a ten-digit number (actually, the last 156 digit can be the letter "X" as well, as described below) 157 which is divided into four variable length parts usually 158 separated by hyphens when printed. The parts are as follows 159 (in this order): 161 * a group identifier which specifies a group of publishers, 162 based on national, geographic or some other criteria, 164 * the publisher identifier, 166 * the title identifier, 168 * and a modulus 11 check digit, using X instead of 10. 170 The group and publisher number assignments are managed in 171 such a way that the hyphens are not needed to parse the ISBN 172 unambiguously into its constituent parts. However, the ISBN 173 is normally transmitted and displayed with hyphens to make 174 it easy for human beings to recognize these parts without 175 having to make reference to or have knowledge of the number 176 assignments for group and publisher identifiers. 178 3.2 Encoding Considerations and Lexical Equivalance 180 Embedding ISBNs within the URN framework presents no 181 particular encoding problems, since all of the characters 182 that can appear in an ISBN are valid in the identifier 183 segment of the URN. %-encoding, as described in [MOATS] is 184 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 202 versions of the same work, or versions of the same work 203 distinguished in some other way (e.g.published for example in 204 the US and in Europe). The choice of whether to assign a new 205 ISBN or to reuse an existing one when publishing a revised 206 printing of an existing edition of a work or even a revised 207 edition of a work is somewhat subjective. Practice varies 208 from publisher to publisher (indeed, the distinction between 209 a revised printing and a new edition is itself somewhat 210 subjective). The use of ISBNs within the URN framework 211 simply reflects these existing practices. Note that it is 212 likely that an ISBN URN will often resolve to many instances 213 of the work (many URLs). 215 4. International Standard Serials Numbers 217 4.1 Overview 219 International Standard Serials Numbers (ISSN) identify a 220 work that is published on a continued basis in issues; they 221 identify the entire (often open-ended, in the case of an 222 actively published) work. ISSNs are defined by the 223 international standards ISO 3297:1986 [ISO2] and ISO/DIS 224 3297 [ISO3] and within the United States by NISO Z39.9-1992 225 [NISO1]. The ISSN International Centre is located in Paris and coordinates 226 a network of regional centers. The National 227 Serials Data Program within the Library of Congress is the US 228 Center of this network. 230 ISSNs have the form NNNN-NNNN where N is a digit, the last 231 digit may be an upper case X as the result of the check 232 character calculation. Unlike the ISBN the ISSN components 233 do not have much structure; blocks of numbers are passed out 234 to the regional centers and publishers. 236 4.2 Encoding Considerations and Lexical Equivalance 238 Again, there is no problem representing ISSNs in the 239 namespace-specific string of URNs since all characters valid 240 in the ISSN are valid in the namespace-specific URN string, 241 and %-encoding is never required. 243 Example: URN:ISSN:1046-8188 245 Supplementary comparison rules are also appropriate for the 246 ISSN namespace. Just as for ISBNs, hyphens should be 247 dropped prior to comparison and occurrences of 'x' 248 normalized to uppercase. 250 4.3 Additional Considerations 252 The ISSN standard and related community implementation 253 guidelines specify when new ISSNs should be assigned vs. 254 continuing to use an existing one. There are some 255 publications where practice within the bibliographic 256 community varies from institution to insitution, such as 257 annuals or annual conference proceedings. In some cases 258 these are treated as serials and ISSNs are used, and in some 259 cases they are treated as monographs and ISBNs are used. For 260 example SIGMOD Record volume 24 number 2 June 1995 contains 261 the Proceedings of the 1995 ACM SIGMOD International 262 Conference on Management of Data. If you subscribe to the 263 journal (ISSN 0163-5808) this is simply the June issue. On 264 the other hand you may have acquired this volume as the 265 conference proceedings (a monograph) and as such would use 266 the ISBN 0-89791-731-6 to identify the work. There are also 267 varying practices within the publishing community as to when 268 new ISSNs are assigned due to the change in the name of a 269 periodical (e.g. Atlantic becomes Atlantic Monthly); or when 270 a periodical is published both in printed and electronic 271 versions (e.g. The New York Times). The use of ISSNs in URNs 272 will reflect these judgments and practices. 274 5. Serial Item and Contribution Identifiers 276 5.1 Overview 278 The standard for Serial Item and Contribution Identifiers 279 (SICI) codes, which has recently been extensively revised, 280 is defined by NISO/ANSI Z39.56-1997 [NISO2]. The maintenance 281 agency for the SICI code is the UnCover Corporation. 283 SICI codes can be used to identify an issue of a serial, or 284 a specific contribution (e.g., an article, or the table of 285 contents) within an issue of a serial. SICI codes are not 286 assigned, they are constructed based on information about 287 the issue or issue component in question. 289 The complete syntax for the SICI code will not be discussed 290 here; see NISO/ANSI Z39.56-1997 [NISO2] for details. 291 However, an example and brief review of the major components 292 is needed to understand the relationship with the ISSN and 293 how this identifier differs from an ISSN. An example of a 294 SICI code is: 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) for 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 and Lexical Equivalance 318 The character set for SICIs is intended to be email- 319 transport-transparent, so it does not present major problems. 320 However, all printable excluded and reserved characters from 321 the URN syntax are valid in the SICI character set and must 322 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 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. It is best left 335 to resolver systems which try to determine if two SICIs refer 336 to the same content. Consequently, we do not propose any 337 specific rules for equivalence testing through lexical manipulation. 339 5.3 Additional Considerations 341 Since the serial is identified by an ISSN, some of the 342 ambiguity currently found in the assignment of ISSNs carries 343 over into SICI codes. In cases where an ISSN may refer to a 344 serial that exists in multiple formats, the SICI contains a 345 qualifier that specifies the format type (for example, 346 print, microform, or electronic). SICI codes may be 347 constructed from a variety of sources (the actual issue of 348 the serial, a citation or a record from an abstracting 349 service) and, as such are based on the principle of using 350 all available information, so there may be multiple SICI 351 codes representing the same article [NISO2, Appenidx D]. 352 For example, one code might be constructed with access to 353 both chronology and enumeration (that is, date of issue and 354 volume, issue and page number), another code might be 355 constructed based only on enumeration information and 356 without benefit of chronology. Systems that use SICI codes 357 employ complex matching algorithms to try to match SICI 358 codes constructed from incomplete information to SICI codes 359 constructed with the benefit of all relevant information. 361 6. Security Considerations 363 This document proposes means of encoding several existing 364 bibliographic identifiers within the URN framework. This 365 documentent does not discuss resolution; thus questions of 366 secure or authenticated resolution mechanisms are out of 367 scope. It does not address means of validating the integrity 368 or authenticating the source or provenance of URNs that 369 contain bibliographic identifiers. Issues regarding 370 intellectual property rights associated with objects 371 identified by the various bibliographic identifiers are also 372 beyond the scope of this document, as are questions about 373 rights to the databases that might be used to construct 374 resolvers. 376 7. References 378 [ISO1] NISO/ANSI/ISO 2108:1992 Information and documentation 379 -- International standard book number (ISBN) 381 [ISO2] ISO 3297:1986 Documentation -- International standard 382 serial numbering (ISSN) 384 [ISO3] ISO/DIS 3297 Information and documentation -- 385 International standard serial numbering (ISSN) 386 (Revision of ISO 3297:1986) 388 [Moats] R. Moats, URN Syntax RFC 2141 May 1997. 390 [NISO 1] NISO/ANSI Z39.9-1992 International standard serial 391 numbering (ISSN) 393 [NISO 2] NISO/ANSI Z39.56-1997 Serial Item and Contribution 394 Identifier 395 [Sollins & Masinter] K. Sollins and L. Masinter, "Functional 396 Requirements for Uniform Resource Names", RFC 1737 397 December 1994. 399 8. Author's Addresses 401 Clifford Lynch 402 Executive Director 403 Coalition for Networked Information 404 21 Dupont Circle 405 Washington, DC 20036 406 cliff@cni.org 408 Cecilia Preston 409 Preston & Lynch 410 PO Box 8310 411 Emeryville, CA 94662 412 cecilia@well.com 414 Ron Daniel Jr. 415 Advanced Computing Lab, MS B287 416 Los Alamos National Laboratory 417 Los Alamos, NM, 87545 418 rdaniel@acl.lanl.gov