idnits 2.17.1 draft-ietf-urnbis-rfc3044bis-issn-urn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 7, 2012) is 4187 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) == Unused Reference: 'I-D.ietf-urnbis-rfc3187bis-isbn-urn' is defined on line 815, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-urnbis-rfc2141bis-urn-03 == Outdated reference: A later version (-09) exists of draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-urnbis-rfc3406bis-urn-ns-reg' -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 2611 (Obsoleted by RFC 3406) -- Obsolete informational reference (is this intentional?): RFC 3044 (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3187 (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF URNbis WG P. Godefroy 3 Internet-Draft ISSN International Centre 4 Obsoletes: 3044 (if approved) November 7, 2012 5 Intended status: Standards Track 6 Expires: May 5, 2013 8 Using International Standard Serial Numbers as Uniform Resource Names 9 draft-ietf-urnbis-rfc3044bis-issn-urn-01 11 Abstract 13 The International Standard Serial Number, ISSN, has been the 14 authoritative identifier for continuing resources (which include 15 serials) for more than three decades. Since 2001, the URN (Uniform 16 Resource Name) namespace "ISSN" has been reserved for ISSNs. The 17 namespace registration was performed in RFC 3044. This document 18 redefines -- in a backwards compatible manner -- how the revised ISSN 19 standard can be supported within the URN framework, taking into 20 account in particular the latest revision of the ISSN standard in the 21 ISO framework (ISO 3297:2007). Moreover, additional syntax related 22 information required by the RFC 2141[bis] has been included. An 23 updated namespace registration is provided. This document replaces 24 RFC 3044. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 5, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 74 3. Fundamental Namespace and Community Considerations . . . . . . 5 75 3.1. The URN:ISSN Namespace . . . . . . . . . . . . . . . . . . 5 76 3.2. Community Considerations for ISSNs . . . . . . . . . . . . 5 77 4. International Standard Serial Numbers . . . . . . . . . . . . 6 78 4.1. Overview / Namespace Considerations . . . . . . . . . . . 6 79 4.1.1. Allocation of Blocks of ISSNs . . . . . . . . . . . . 7 80 4.2. ISSN Structure . . . . . . . . . . . . . . . . . . . . . . 8 81 4.3. Encoding Considerations . . . . . . . . . . . . . . . . . 8 82 4.4. Resolution of ISSN-based URNs . . . . . . . . . . . . . . 9 83 4.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.4.2. Practical Aspects . . . . . . . . . . . . . . . . . . 9 85 4.5. Additional Considerations . . . . . . . . . . . . . . . . 10 86 4.5.1. ISSN-L (or "Linking ISSN") . . . . . . . . . . . . . . 10 87 4.5.2. Updating and Management of URLs Corresponding to 88 Resources Identified by URN:ISSN . . . . . . . . . . . 12 89 5. URN Namespace Registration and Use . . . . . . . . . . . . . . 14 90 5.1. URN Namespace ID Registration for the International 91 Standard Serial Number (ISSN) . . . . . . . . . . . . . . 14 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 1. Introduction 102 One of the basic permanent URI schemes (cf. RFC 3986 [RFC3986], 103 [IANA-URI]) is 'URN' (Uniform Resource Name) as originally defined in 104 RFC 2141 [RFC2141] and now being formally specified in RFC 2141bis 105 [I-D.ietf-urnbis-rfc2141bis-urn]. Any identifier, when used within 106 the URN system, needs its own namespace. In August 2011 there were 107 44 registered URN namespaces (see [IANA-URN]), one of which belongs 108 to ISSN, International Standard Serial Number, as specified 2001 in 109 RFC 3044 [RFC3044]. 111 As part of the validation process for the development of URNs, the 112 IETF URN working group agreed that it is important to demonstrate 113 that a URN syntax proposal can accommodate existing identifiers from 114 well established namespaces. One such infrastructure for assigning 115 and managing names comes from the bibliographic community. 116 Bibliographic identifiers function as names for objects that exist 117 both in print and, increasingly, in electronic formats. RFC 2288 118 [RFC2288] investigated the feasibility of using three identifiers 119 (ISBN, ISSN and SICI, see below) as URNs, with positive results; 120 however, it did not formally register corresponding URN namespaces. 121 This was in part due to the still evolving process to formalize 122 criteria for namespace definition documents and registration, 123 consolidated later in the IETF into RFC 3406 [RFC3406]. That RFC, in 124 turn, is now being updated as well into RFC 3406bis 125 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]. 127 URN Namespaces have subsequently been registered for both ISBN 128 (International Standard Book Number) and ISSN (International Serial 129 Standard Number) in RFCs 3187 and 3044 ([RFC3187], [RFC3044]), 130 respectively. 132 The RFC at hand replaces RFC 3044; all ISSN information has been 133 updated and the namespace registration revised to make it compliant 134 with stipulations of RFC 3406bis 135 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg], the work-in-progress 136 successor of RFC 3406 [RFC3406], which in turn had replaced the 137 legacy RFC 2611 [RFC2611] applied in the initial registration. This 138 version of the URN:ISSN registration is fully backwards compatible 139 with the original one, in the sense that all ISSN URNs assigned under 140 RFC 3044 remain valid and semantically unchanged. 142 2. Conventions Used in This Document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 3. Fundamental Namespace and Community Considerations 150 3.1. The URN:ISSN Namespace 152 ISSN is an authoritative standard identifier system for continuing 153 resources and in particular serial publications. Therefore, any 154 useful and deployable method for identifying these entities for 155 network-wide reference and making their metadata available on the 156 Internet needs to be based on ISSNs. ISSNs are authoritatively 157 referenced in a centrally managed database called the "ISSN 158 Register", which can be used as the basis for URN:ISSN resolution 159 services. 161 3.2. Community Considerations for ISSNs 163 ISSNs are assigned under the auspices of the ISSN International 164 Centre and national ISSN Centres. ISSN assignment is a well managed 165 and understood process, but as in any process administered by humans 166 errors do take place. While some errors may happen in the ISSN 167 Register itself and are readily corrected, most errors happen in the 168 outside world through the use of inappropriate ISSN in external 169 references or the resources themselves. 171 Continuing resources, including serials, most often consist of 172 component parts such as volumes, issues, articles. The ISSN standard 173 does not allow the identification of component parts of the serial 174 designated by the ISSN, and the URN:ISSN Namespace equally does not 175 support such augmentation -- neither by an added NSS component nor by 176 use of URI fragment identifiers. 178 For all the communities interested in the identification of 179 continuing resources and their contents, URN:ISSN-based 180 identification and resolution services offer efficient, reliable and 181 persistent access to resources and/or resource-related services. The 182 users will not need special tools for this as Web browsers are 183 sufficient to display bibliographic information or when appropriate, 184 an access point to the resources themselves. 186 The next chapter presents an overview of the application of the URN: 187 ISSN namespace and the principles, and systems used, for the 188 resolution of ISSN-based URNs. 190 4. International Standard Serial Numbers 192 4.1. Overview / Namespace Considerations 194 Each ISSN is a unique identifier for a specific serial or other 195 continuing resource in a defined medium. 197 ISSNs are applicable to serials and other continuing resources, 198 whether past, present, or to be produced in the foreseeable future, 199 whatever the medium of production. Continuing resources are issued 200 over time with no predetermined conclusion, they include serials and 201 ongoing integrating resources. ISSNs are assigned to the entire 202 population of serials and to ongoing integrating resources. 204 Serials are resources for which additional information is supplied 205 indefinitely in a succession of discrete parts. All serials are 206 eligible for an ISSN. Also eligible for ISSN assignment are those 207 bibliographic resources issued in successive issues or parts that 208 bear numbering and that also bear other characteristics of a serial 209 (e.g. frequency in the title), but whose duration is limited (e.g. 210 the newsletter of an event). 212 Ongoing integrating resources are resources that are updated over 213 time and with no predetermined conclusion, for which the updates are 214 integrated into the resources and do not remain discrete. Those 215 ongoing integrating resources that are eligible for an ISSN must be 216 updated indefinitely, and/or have an update statement. Advertising 217 and individual home pages, online diaries, personal weblogs, and web 218 sites consisting exclusively of links are not eligible for an ISSN. 220 Individual monographs, technical reports, sound and video recordings, 221 printed music publications, audiovisual works and musical works have 222 their own identifier systems. Such items may carry an ISSN in 223 addition to their own standard numbers when they are part of a 224 continuing resource. 226 Only one ISSN is assigned to a continuing resource in a defined 227 medium. This ISSN is permanently linked to the so called key title, 228 a standardized form of title derived from information appearing on 229 the continuing resource. A key title is unique to a particular 230 continuing resource. Titles that would otherwise not be unique are 231 made unique by the addition of qualifying elements. In cases where 232 the title changes sufficiently (as per specific rules defined in the 233 ISSN Manual) to warrant creating a new key title, a new ISSN is 234 assigned. In cases where the medium of the continuing resource 235 changes, a new ISSN and a new key title are assigned. 237 Changes in publisher, country, language, frequency, subject scope or 238 any other characteristic of a given continuing resource do not 239 warrant the assignment of a new ISSN. Title changes that are deemed 240 minor are registered in the ISSN metadata as "variant titles". 242 When a new ISSN is assigned to a continuing resource (because of a 243 significant title change or of a media change), both the "former" and 244 "new" ISSN are deemed valid and identify two distinct entities: each 245 of them identifies the continuing resource in its incarnation in a 246 given time interval, under a particular key title and/or physical 247 medium. "Dead" continuing resources are dead in the sense that they 248 are no longer updated, but they continue to be accessible in library 249 shelves or as archives on servers and their continuing identification 250 is an obvious need for the whole chain of stakeholders. 252 In such cases, ISSNs, through the metadata stored in the ISSN records 253 of the ISSN Register are reciprocally linked. In fact, one of the 254 major aspects of the ISSN Register is its linking structure through 255 which various incarnations of continuing resources are reciprocally 256 linked using the ISSN as pointer. There are different categories of 257 such links (for former and successor titles, other media editions, 258 other language editions, supplements etc.). A given ISSN may thus be 259 linked directly to a number of other ISSN, which in turn may be 260 linked to other ISSNs, etc. We can thus define the concepts of 261 directly and indirectly linked ISSNs. 263 4.1.1. Allocation of Blocks of ISSNs 265 The ISSN International Centre is responsible for the allocation of 266 blocks of ISSN to National Centres. Each Centre receives limited 267 blocks of numbers. In using blocks of ISSNs, National ISSN Centres 268 adhere to the following procedures: 270 I. Report all ISSNs assigned by their centre to the ISSN Register; 272 II. Assign the ISSNs within their allocated block consecutively and 273 use up one block completely before starting another block; 275 III. Ensure that ISSN assignments made in advance of publication or 276 production of a continuing resource are recorded in the ISSN Register 277 by determining if publication or production of the resource has 278 occurred and creating the appropriate ISSN records. 280 Although it is possible, on the basis of internal management 281 procedures of the ISSN Register, to determine in a majority of cases 282 that a given ISSN is part of a given block of ISSNs allocated to a 283 given ISSN National Centre, this feature cannot be used for ISSN 284 resolution mechanisms for the following reasons: 286 - The country of publication of a continuing resource may change 287 over time (which implies that the responsibility of a given ISSN 288 may be switched from one ISSN National Centre to another and that 289 the ISSN block from which the given ISSN was used may not 290 correspond to the actual country of publication). 292 - A significant number of ISSNs were initially assigned in a 293 "multinational" framework where the block of ISSNs was not 294 attached to a given country. 296 - There exists a significant number of "multinational" publications 297 where "national" responsibility for ISSN assignment and management 298 has necessarily to be defined on somewhat arbitrary basis, which 299 may vary over time. 301 For similar or identical reasons, although metadata attached to an 302 ISSN in the framework of the ISSN Register defines the current 303 National ISSN Centre responsible for the management of the ISSN and 304 its corresponding ISSN record, this information cannot and should not 305 be used to infer a resolution path. 307 4.2. ISSN Structure 309 An ISSN consists of eight digits. These are the Arabic numerals 0 to 310 9, except that an upper case X can sometimes occur in the final 311 position as a check digit (when representing the number "10"). Since 312 ISSNs are likely to be used in the same context as codes designed for 313 other purposes, a distinction must be preserved in the form of 314 presentation. An ISSN therefore appears as two groups of four 315 digits, separated by a hyphen: 317 ISSN 0317-8471 319 ISSN 1050-124X 321 The check digit is always located in the extreme right (low order) 322 position, and is calculated on a modulus 11 basis using weights 8 to 323 2. 325 4.3. Encoding Considerations 327 Embedding ISSNs within the URN framework does not present encoding 328 problems, since all of the characters that can appear in an ISSN (the 329 10 digits (0 to 9), the hyphen and capital letter X) are valid in the 330 namespace-specific string (NSS) part of the URN. Percent-encoding, 331 as described in RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn], is 332 never needed. In order to improve readability of the NSS, central 333 hyphens SHOULD always be used. 335 Example: URN:ISSN:1234-1231 337 4.4. Resolution of ISSN-based URNs 339 4.4.1. General 341 For URN resolution purposes, all elements, including the check digit 342 and the central hyphen, must be taken into account. 344 If a local resource stores and manages ISSNs without a central 345 hyphen, it SHOULD be programmatically inserted for the constitution 346 of URN:ISSN. 348 Applications, such as the national bibliography or the open archive 349 of a university, can use the URN as the persistent address of the 350 resource. There is just one place (the URN registry) where the 351 address is mapped to one or more physical locations. 353 4.4.2. Practical Aspects 355 Persistence is one of the key features for any persistent identifier 356 system. There are three inter-related aspects of persistence that 357 need to be discussed: persistence of the resource itself, persistence 358 of the identifier, and persistence of the URN-based resolvers. 360 Persistence of the resources: continuing resources are complex 361 objects that evolve over time. In their (mostly) paper incarnations, 362 they have been stored on library shelves sometimes for centuries. 363 Bibliographic records mediate identification and access. If a 364 continuing resource is available on print only, its URN:ISSN will 365 resolve to the bibliographic record in the ISSN register. 367 The ISSN Register has identified (at the beginning of 2012) almost 368 100,000 online continuing resources that may or may not have print 369 equivalents. Furthermore, vast digitization efforts are now 370 undertaken over the world to create electronic archives of printed 371 continuing resources (these initiatives have often a dual aim of long 372 term preservation and economies in shelving space); efforts are also 373 under way to manage the long term preservation of online continuing 374 resources. 376 All these efforts that have as a goal the persistence of the 377 continuing resources will be all the more successful if they benefit 378 from a standardized identification layer. This obviously also has an 379 impact on the management of contents (volumes, issues, and first and 380 foremost articles) where linking frameworks that appeared during the 381 last ten years (CROSSREF or Open URL) make heavy use of the ISSN. 383 Persistence of the identifier: The ISSN as an identifier is 384 persistent in the sense that once assigned, an ISSN will never be re- 385 assigned to a different continuing resource. 387 Persistence of the resolvers: URN resolvers are not static. The 388 services they'll supply will change over time, due to changes in 389 technical infrastructure. For instance, new URN resolution services 390 may be added or modified over time. Persistence of the resolvers 391 themselves is mainly an organizational issue, related to the 392 persistence of organizations maintaining them. As URN:ISSN 393 resolution services will be based on the ISSN Register, which is 394 itself a persistent resource that has been maintained for almost 35 395 years, we may thus assume that URN:ISSN resolution services will be 396 persistent. 398 The ISSN Register will initially support four resolution services 399 specified in RFC 2483 [RFC2483], namely I2L, I2Ls, I2C and I2Cs. 400 Only I2C and I2Cs (URI to URC(s); delivery of descriptive metadata 401 related to the resource) are valid for non-networked resources. 402 Descriptive metadata can only be supplied in the MARC21 format. The 403 resolutions service will be conformant with the syntax defined for 404 the query instruction for URN service selection specified in 405 RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn]. 407 Due to the structure of the ISSN, it is assumed that URN:ISSN 408 resolution can only be reliably achieved through a central service, 409 based on the ISSN Register that in turn can benefit from automated 410 linking with other local resources using the ISSN as an identifier. 411 Only a combination of the authority of the centralized ISSN Register 412 and of local data can guarantee both reliability and persistence. 414 4.5. Additional Considerations 416 4.5.1. ISSN-L (or "Linking ISSN") 418 In the framework of URN:ISSN resolution, the ISSN-L is a very 419 important new feature. 421 The ISSN-L (or "linking ISSN") is an important modification 422 introduced in the latest revision of the ISSN standard in the ISO 423 framework. 425 The ISSN-L has been defined to meet the need for a collocation, or 426 grouping mechanism that brings together the various media versions of 427 a continuing resource, and thus facilitate content management. 429 The ISSN-L is an ISSN designated by the ISSN Network to group the 430 different media versions of a continuing resource. 432 Only one ISSN-L is designated regardless of how many different media 433 versions of a continuing resource exist. A continuing resource will 434 be associated with only one ISSN-L. 436 4.5.1.1. Designation of the ISSN-L 438 The designation of the ISSN-L is carried out either by a centre of 439 the ISSN Network or is performed automatically as records are added 440 to the ISSN Register. It is done either by those ISSN National 441 Centres that are able to undertake this responsibility, or by the 442 International Centre. The records produced by these National Centres 443 include the ISSN-L in the ISSN records under their responsibility. 445 4.5.1.2. Rules for the Designation of the ISSN-L 447 The first ISSN assigned, in the ISSN Register, to any media version 448 of a continuing resource is designated by default to function also as 449 the ISSN-L and applies to all other media versions of that resource 450 identified in the ISSN Register. An ISSN-L is designated for each 451 continuing resource identified in the ISSN Register, even if the 452 continuing resource is issued in only one medium. Only one ISSN-L is 453 designated regardless of how many different media versions of a 454 continuing resource exist. 456 In the framework of URN:ISSN resolution, whether an ISSN is submitted 457 as an ISSN-L or as an ISSN should be considered as having no 458 practical impact as the response should always include by default 459 basic resolution data for all ISSNs that may be linked through a 460 common ISSN-L. 462 For efficient practical resolution purposes, it should not be assumed 463 that the requesting service has an unambiguous knowledge of either: 465 o the media version associated to a given ISSN; or 467 o the ISSN which is designated to function as the ISSN-L that links 468 the different media versions. 470 The URN:ISSN resolution service should make no such assumption 471 concerning the knowledge of the requesting service. The URN:ISSN 472 resolution should make available sufficient authoritative metadata so 473 as to allow the requesting service to obtain the expected response, 474 even if the ISSN submitted is not used fully adequately by the 475 requestor. URN:ISSN resolution metadata should allow the requesting 476 service to check and correct if necessary its potentially incorrect 477 assumptions, so as to avoid the following situations: 479 o an ISSN would be left unresolved (for instance because a "print" 480 ISSN was sent instead of the "online" ISSN and I2L service is 481 requested); 483 o the requesting service would be left unaware of the existence of 484 other ISSN linked through a common linking ISSN-L, because it 485 would have submitted for resolution an ISSN not designated as 486 ISSN-L; 488 o the requesting service would have to perform several successive 489 URN:ISSN resolution requests for all ISSN linked through a common 490 ISSN-L. 492 Examples: 494 URN:ISSN:1234-1231 identifies the current print edition of 495 "Medical News". 497 URN:ISSN:1560-1560 identifies the current online edition of 498 "Medical News". 500 The ISSN-L linking both media versions of "Medical News" happens to 501 be ISSN-L 1234-1231 (i.e based on the ISSN 1234-1231, designated as 502 such in the framework of the management of the ISSN Register). 504 The resolution of URN:ISSN:1234-1231 should be equivalent to the 505 resolution of URN:ISSN 1560-1560; i.e., in both cases one should find 506 a reference to the other media version. 508 4.5.2. Updating and Management of URLs Corresponding to Resources 509 Identified by URN:ISSN 511 As already indicated, continuing resources are complex objects or 512 sets of objects that evolve over time and can be partly or fully 513 duplicated, published, archived, remixed. Various entities 514 (publishers, issuing bodies, libraries, content aggregators, 515 archiving institutions, subscription services, ...) may be partly or 516 fully responsible over time for the online management of these 517 objects. 519 Their stewardship may be ambiguously implemented for various reasons: 521 o It may extend over a restricted sub-set of the resource (only from 522 a given year for instance). 524 o It may express itself over time through various technical 525 implementations, which may translate into server name and URL 526 changes. 528 o It may or may not be associated with an adequate stewardship over 529 the appropriate identification of the objects (inadequate ISSN 530 being used for media versions, title changes not taken into 531 account, ...). 533 o The ISSN assigned may or may not be used in a consistent and 534 standardized machine processable form in the objects themselves or 535 in external reference lists. Even if an appropriate ISSN is used 536 in the stored metadata, it may be duplicated at the level of all 537 the sub-objects (volumes, issues, articles, ...) making it 538 impractical to ascertain the adequate entry point of the 539 continuing resource itself as a whole. 541 In some cases, continuing resources are not processed or managed as 542 such and only their constituent parts (for instance, volumes, issues, 543 articles, ...) are made directly accessible as evolving sets. 545 Last but not least, commercial publications may restrict access to 546 authenticated users only. 548 This practically means that "resolution" (in the sense of 549 localization) of continuing resources can best be achieved in the 550 framework of long term coordinated efforts, but cannot be guaranteed 551 in all cases. The best results will of course be obtained with 552 "preservation silos" or big entities. Concerning the "long tail" of 553 small publications, preservation initiatives are best equipped to 554 handle the link between identification and access to the resources 555 themselves. 557 This means that URN:ISSN resolution will not be able to offer "full 558 resolution" (i.e. reliable access to the resource itself) in all 559 cases, even if the resource is "online". 561 On the other hand, URN:ISSN extended resolution services could be 562 offered on a systematic basis thanks to the metadata stored in the 563 ISSN Register and its potential linking with external resources, such 564 as: 566 o basic metadata stored in the ISSN Register identifying or 567 describing the resource, including, as stated above, metadata from 568 the ISSN records linked through a common ISSN-L; in particular, 569 the minimum set of data should include the category of the ISSN as 570 defined above, so as to allow for instance an adequate processing 571 of "cancelled ISSNs"; 573 o access to the direct or indirect linking structure associating the 574 ISSN with other continuing resources; 576 o linking to administrative metadata such as archiving and 577 preservation information about the resource or in a more general 578 and wider way, to any kind of relevant ancillary information: 579 publisher, issuing body, availability through third party outfits, 580 such as union catalogues etc., external evaluation and 581 authentication data, in fact to any other party or service 582 offering relevant ISSN based metadata. 584 URN:ISSN resolution services can be both human readable and machine 585 processable so as to support semantic web compatible services. 587 It should finally be noted that as the ISSN Register is a 588 subscription based resource, URN:ISSN resolution cannot be a fully 589 open service. 591 5. URN Namespace Registration and Use 593 The formal URN Namespace Identifier Registration for the pre-2007 594 version of the International Standard Serial Number (ISSN) standard 595 was done in RFC 3044 [RFC3044]. 597 The revised ISSN standard does not require a new namespace, but the 598 registration is updated here. The registrant organization has moved 599 from a former address to a new one in Paris. Moreover, the 600 description of the NSS and resolution details have been amended. 602 5.1. URN Namespace ID Registration for the International Standard 603 Serial Number (ISSN) 605 This registration describes how the International Standard Serial 606 Number (ISSN) can be supported within the URN framework. 608 [ RFC Editor: please replace "XXXX" in all instances of "RFC XXXX" 609 below by the RFC number assigned to this document. ] 611 Namespace ID: ISSN 613 This Namespace ID has already been assigned to the International 614 Standard Serial Number in January 2001 when the namespace was 615 initially registered. 617 Kind of named resources: 619 Continuing (serial) publications. 621 Registration Information: 623 Version: 2 624 Date: 2012-10-31 626 Declared registrant of the namespace: 628 Registering Organization: Centre international d'Enregistrement 629 des Publications en Serie - CIEPS-ISSN - ISSN International Centre 631 Designated Contact Person: 632 Name: Ms. Francoise Pelle 633 Affiliation: Director, ISSN International Centre 634 Email: issnic@issn.org 635 Postal: 45 rue de Turbigo, 75003 PARIS, FRANCE 636 Web URL: 638 Declaration of syntactic structure of NSS part: 640 The ISSN syntax (used literally as the NSS) is as follows: 642 NNNN-NNNC 644 where N is a Digit character [0..9] 645 C is either a Digit character or letter "X" [0..9,X] 646 C is the check character 648 Example 1: URN:ISSN:1234-1231 649 Example 2: URN:ISSN: 0259-000X 651 Relevant ancillary documentation: 653 The ISSN (International Standard Serial Number) is a unique 654 machine-readable identification number, which identifies 655 unambiguously any continuing resource. This number is defined in 656 ISO Standard 3297:2007. ISSNs have been in use for more than 30 657 years and they have deeply affected the handling of continuing 658 resources and their contents. 88 countries are officially ISSN 659 members (at the beginning of 2012). 661 The administration of the ISSN system is carried out at two 662 levels: International Centre and National Centres. 664 The ISSN International Centre is located in Paris (France). 665 The main functions of the Centre are: 667 * To promote, co-ordinate and supervise the world-wide use of the 668 ISSN system. 670 * To maintain and publish the ISSN Register. 672 * To allocate blocks of ISSNs to ISSN National Centres. 674 * to assign ISSN to international publications and to serials 675 issued in countries with no National Centre. 677 Detailed information about ISSN usage can be found from the ISSN 678 Users' Manual. The manual is available at 679 681 Conformance with URN Syntax: 683 Legal ISSN characters are 0-9 and hyphen and X. No percent- 684 encoding is needed. Hyphen carries no semantic content but SHOULD 685 NOT be dropped from the NSS. 687 Rules for Lexical Equivalence of NSS part: 689 ISSN numbers are usually printed with the letters 'ISSN' and a 690 single blank preceding the ISSN proper (for instance: ISSN 1234- 691 1231). Any data preceding the ISSN MUST NOT be included in the 692 NSS. No percent encoding is needed. 694 Prior to comparing the NSS of two ISSN-based URNs for equivalence, 695 all hyphens, if present, MUST be removed and letter 'X' 696 capitalized. 698 Note that, according to RFC 2141bis 699 [I-D.ietf-urnbis-rfc2141bis-urn], the prefix "URN:ISSN:" is case- 700 insensitive; generic URI parsing and comparison software 701 frequently uses lower case as the canonical (normalized) form. 703 The URNs are equivalent if the normalized forms obtained this way 704 compare equal. 706 Usage of query instructions: 708 'ISSN' URN resolvers initially support four of the resolution 709 services specified in RFC 2483 [RFC2483], namely I2L, I2Ls, I2C 710 and I2Cs. Only I2C and I2Cs (URI to URC(s); delivery of 711 descriptive metadata related to the resource) are valid for non- 712 networked resources, and hence I2C is the default service. 714 'ISSN' URN resolution by the ISSN International Centre will ignore 715 query keywords other than "s". 717 Usage of fragment part: 719 There are no provisions for support of the fragment part in URI 720 references to 'ISSN' URNs. 721 However, the MARC21 format used to return metadata for 'ISSN' URNs 722 can be interpreted by cognizant resolution clients. 724 Identifier uniqueness and persistence considerations: 726 ISBN is a unique identifier. ISSN is a unique and persistent 727 identifier. An ISSN, once it has been assigned, MUST NOT be re- 728 used for another continuing resource. 'ISSN' URNs inherit the 729 uniqueness and persistence properties from ISSNs. 731 Process of identifier assignment: 733 Assignment of ISSNs is controlled, and 'ISSN' URNs immediately 734 inherit this property. There are three levels of control: the 735 ISSN International Centre, national ISSN Centres, and finally all 736 the stakeholders responsible for a correct use of the ISSN system. 738 Process for identifier resolution: 740 See Section 4.4 of RFC XXXX. 742 Validation mechanism: 744 The check digit helps to assure the correctness of an ISSN number 745 assigned for a continuing resource when it has been entered or 746 processed. Applications processing bibliographic data such as 747 integrated library systems MAY use the check digit to check the 748 correctness of the ISSN string. If the number is found to be 749 wrong due to, e.g., a typing error made by a publisher, the 750 correct ISSN SHOULD nevertheless be used while the wrong number 751 may be stored alongside for reference. Although the resource 752 itself may only contain the wrong number, national bibliographies 753 and systems used by relevant communities often will contain both 754 the wrong and correct ISSN number. 756 Scope: 758 ISSN is a global identifier system used for identification of 759 continuing resources. It is very widely used and supported by the 760 publishing and scholarly publication communities. 762 6. Security Considerations 764 This document proposes means of encoding ISSNs within the URN 765 framework. An ISSN-based URN resolution service is depicted here, 766 but in a generic level only; thus questions of secure or 767 authenticated resolution mechanisms are excluded. It does not deal 768 with means of validating the integrity or authenticating the source 769 or provenance of URNs that contain ISSNs. Issues regarding 770 intellectual property rights associated with objects identified by 771 the ISSNs are also beyond the scope of this document. 773 Access control mechanisms may be implemented to limit access to some 774 or all URN resolution services available in the URN Register. Such 775 mechanisms, if any, will be discussed separately. 777 7. IANA Considerations 779 IANA is asked to update the existing registration of the Formal URN 780 Namespace 'ISSN' using the template given above in Section 5.1, which 781 follows the outline specified in RFC 3406bis 782 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]. 784 8. Acknowledgements 786 This draft is part of the URNBIS effort to revise the basic URN RFCs. 787 The aim in the IETF is to bring these RFCs in alignment with the 788 current URI Standard (STD 63, RFC 3986), ABNF, and IANA guidelines. 789 The PERSID project is a significant impulse 790 to this work. 792 9. References 794 9.1. Normative References 796 [I-D.ietf-urnbis-rfc2141bis-urn] 797 Hoenes, A., "Uniform Resource Name (URN) Syntax", 798 draft-ietf-urnbis-rfc2141bis-urn-03 (work in progress), 799 October 2012. 801 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg] 802 Hoenes, A., "Defining Uniform Resource Name (URN) 803 Namespaces", draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03 804 (work in progress), October 2012. 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", BCP 14, RFC 2119, March 1997. 809 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 810 Resource Identifier (URI): Generic Syntax", STD 66, 811 RFC 3986, January 2005. 813 9.2. Informative References 815 [I-D.ietf-urnbis-rfc3187bis-isbn-urn] 816 Huttunen, M., Hakala, J., and A. Hoenes, "Using 817 International Standard Book Numbers as Uniform Resource 818 Names", draft-ietf-urnbis-rfc3187bis-isbn-urn-03 (work in 819 progress), October 2012. 821 [IANA-URI] 822 IANA, "URI Schemes Registry", 823 . 825 [IANA-URN] 826 IANA, "URN Namespace Registry", 827 . 829 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 831 [RFC2288] Lynch, C., Preston, C., and R. Jr, "Using Existing 832 Bibliographic Identifiers as Uniform Resource Names", 833 RFC 2288, February 1998. 835 [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services 836 Necessary for URN Resolution", RFC 2483, January 1999. 838 [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 839 "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, 840 June 1999. 842 [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial 843 Standard Number) as URN (Uniform Resource Names) within an 844 ISSN-URN Namespace", RFC 3044, January 2001. 846 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard 847 Book Numbers as Uniform Resource Names", RFC 3187, 848 October 2001. 850 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 851 "Uniform Resource Names (URN) Namespace Definition 852 Mechanisms", BCP 66, RFC 3406, October 2002. 854 Author's Address 856 Pierre Godefroy 857 ISSN International Centre 858 45 rue de Turbigo 859 Paris, 75003 860 France 862 Phone: +33-1-44-88-22-18 863 Email: godefroy@issn.org