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