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