| IETF URNbis WG | P. Godefroy |
| Internet-Draft | ISSN International Centre |
| Obsoletes: 3044 (if approved) | March 05, 2012 |
| Intended status: Standards Track | |
| Expires: September 04, 2012 |
Using International Standard Serial Numbers as Uniform Resource Names
draft-ietf-urnbis-rfc3044bis-issn-urn-00
The International Standard Serial Number, ISSN, has been the authoritative identifier for continuing resources (which include serials) for more than three decades. Since 2001, the URN (Uniform Resource Name) namespace "ISSN" has been reserved for ISSNs. The namespace registration was performed in RFC 3044. This document redefines how the revised ISSN standard can be supported within the URN framework, taking into account in particular the latest revision of the ISSN standard in the ISO framework (ISO 3297:2007). Moreover, additional syntax related information required by the RFC 2141[bis] has been included. An updated namespace registration is provided. This document replaces RFC 3044.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 04, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
One of the basic permanent URI schemes (cf. RFC 3986 [RFC3986], [IANA-URI]) is 'URN' (Uniform Resource Name) as originally defined in RFC 2141 [RFC2141] and now being formally specified in RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn]. Any identifier, when used within the URN system, needs its own namespace. In August 2011 there were 44 registered URN namespaces (see [IANA-URN]), one of which belongs to ISSN, International Standard Serial Number, as specified 2001 in RFC 3044 [RFC3044].
As part of the validation process for the development of URNs, the IETF URN working group agreed that it is important to demonstrate that a URN syntax proposal can accommodate existing identifiers from well established namespaces. One such infrastructure for assigning and managing names comes from the bibliographic community. Bibliographic identifiers function as names for objects that exist both in print and, increasingly, in electronic formats. RFC 2288 [RFC2288] investigated the feasibility of using three identifiers (ISBN, ISSN and SICI, see below) as URNs, with positive results; however, it did not formally register corresponding URN namespaces. This was in part due to the still evolving process to formalize criteria for namespace definition documents and registration, consolidated later in the IETF into RFC 3406 [RFC3406]. That RFC, in turn, is now being updated as well into RFC 3406bis [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg].
URN Namespaces have subsequently been registered for both ISBN (International Standard Book Number) and ISSN (International Serial Standard Number) in RFCs 3187 and 3044 ([RFC3187], [RFC3044]), respectively.
The RFC at hand replaces RFC 3044; all ISSN information has been updated and the namespace registration revised to make it compliant with stipulations of RFC 3406bis [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg], the work-in-progress successor of RFC 3406 [RFC3406], which in turn had replaced the legacy RFC 2611 [RFC2611] applied in the initial registration.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
ISSN is an authoritative standard identifier system for continuing resources and in particular serial publications. Therefore, any useful and deployable method for identifying these entities for network-wide reference and making their metadata available on the Internet needs to be based on ISSNs. ISSNs are authoritatively referenced in a centrally managed database called the "ISSN Register" which can be used as the basis for URN:ISSN resolution services.
ISSNs are assigned under the auspices of the International ISSN International Centre and national ISSN Centres. ISSN assignment is a well managed and understood process, but as in any process administered by humans errors do take place. While some errors may happen in the ISSN Register itself and are readily corrected, most errors happen in the outside world through the use of inappropriate ISSN in external references or the resources themselves.
Continuing resources, including serials, most often consist of component parts such as volumes, issues, articles. The ISSN standard does not allow augmentation of the ISSN of the resource with (URI) fragments for identification of component parts. If a fragment identifier is added to an ISSN, the resulting namespace specific string will not be an ISSN.
For all the communities interested by the identification of continuing resources and their contents, URN:ISSN-based identification and resolution services offer efficient, reliable and persistent access to resources and/or resource-related services. The users will not need special tools for this as Web browsers are sufficient to display bibliographic information or when appropriate, an access point to the resources themselves.
The next chapter presents an overview of the application of the URN: ISSN namespace and the principles, and systems used, for the resolution of ISSN-based URNs.
Each ISSN is a unique identifier for a specific serial or other continuing resource in a defined medium.
ISSN are applicable to serials and other continuing resources, whether past, present, or to be produced in the foreseeable future, whatever the medium of production. Continuing resources are issued over time with no predetermined conclusion, they include serials and ongoing integrating resources. ISSN are assigned to the entire population of serials and to ongoing integrating resources.
Serials are resources for which additional information is supplied indefinitely in a succession of discrete parts. All serials are eligible for an ISSN. Also eligible for ISSN assignment are those bibliographic resources issued in successive issues or parts which bear numbering and that also bear other characteristics of a serial (e.g. frequency in the title), but whose duration is limited (e.g. the newsletter of an event).
Ongoing integrating resources are resources that are updated over time and with no predetermined conclusion, for which the updates are integrated into the resources and do not remain discrete. Those ongoing integrating resources which are eligible for an ISSN must be updated indefinitely, and/or have an update statement. Advertising and individual home pages, online diaries, personal weblogs, and web sites consisting exclusively of links are not eligible for an ISSN.
Individual monographs, technical reports, sound and video recordings, printed music publications, audiovisual works and musical works have their own identifier systems. Such items may carry an ISSN in addition to their own standard numbers when they are part of a continuing resource.
Only one ISSN is assigned to a continuing resource in a defined medium. This ISSN is permanently linked to the so called key title, a standardized form of title derived from information appearing on the continuing resource. A key title is unique to a particular continuing resource. Titles which would otherwise not be unique are made unique by the addition of qualifying elements. In cases where the title changes sufficiently (as per specific rules defined in the ISSN Manual) to warrant creating a new key title, a new ISSN is assigned. In cases where the medium of the continuing resource changes, a new ISSN and a new key title are assigned.
Changes in publisher, country, language, frequency, subject scope or any other characteristic of a given continuing resource do not warrant the assignment of a new ISSN. Title changes which are deemed minor are registered in the ISSN metadata as "variant titles".
When a new ISSN is assigned to a continuing resource (because of a significant title change or of a medium change), both the "former" and "new" ISSN are deemed valid and identify two distinct entities : each of them identifies the continuing resource in its incarnation in a given time interval, under a particular key title and/or physical medium. "Dead" continuing resources are dead in the sense that they are no longer updated, but they continue to be accessible in library shelves or as archives on servers and their continuing identification is an obvious need for the whole chain of stakeholders.
In such cases, ISSNs, through the metadata stored in the ISSN records of the ISSN Register are reciprocally linked. In fact, one of the major aspects of the ISSN Register is its linking structure through which various incarnations of continuing resources are reciprocally linked using the ISSN as pointer. There are different categories of such links (for former and successor titles, other medium editions, other language editions, supplements etc.). A given ISSN may thus be linked directly to a number of other ISSN which in turn may be linked to other ISSNs etc. We can thus define the concepts of directly and indirectly linked ISSNs.
Allocation of blocks of ISSN
The International Centre is responsible for the allocation of blocks of ISSN to National Centres. Each Centre receives limited blocks of numbers. In using blocks of ISSN, National ISSN Centres adhere to the following procedures:
I. Report all ISSN assigned by their centre to the ISSN Register;
II. Use ISSN within their assigned block consecutively and use up one block completely before starting another block;
III. Ensure that ISSN assignments made in advance of publication or production of a continuing resource are recorded in the ISSN Register by determining if publication or production of the resource has occurred and creating the appropriate ISSN records.
Although it is possible, on the basis of internal management procedures of the ISSN Register, to determine in a majority of cases that a given ISSN is part of a given block of ISSN allocated to a given ISSN National Centre, this feature cannot be used for ISSN resolution mechanisms for the following reasons :
- The country of publication of continuing resource may change over time (which implies that the responsibility of a given ISSN may be switched from one ISSN National Centre to another and that the ISSN block from which the given ISSN was used may not correspond to the actual country of publication)
- A significant number of ISSN were initially assigned in a "multinational" framework where the block of ISSN was not attached to a given country
- There exists a significant number of "multinational" publications where "national" responsibility for ISSN assignment and management has necessarily to be defined on somewhat arbitrary basis which may vary over time
For similar or identical reasons, although metadata attached to an ISSN in the framework of the ISSN Register defines current National ISSN Centre responsible for the management of the ISSN and its corresponding ISSN record, this information cannot and should not be used to infer a resolution path.
An ISSN consists of eight digits. These are the Arabic numerals 0 to 9, except that an upper case X can sometimes occur in the final position as a check digit (when representing the number "10"). Since ISSN are likely to be used in the same context as codes designed for other purposes, a distinction must be preserved in the form of presentation. An ISSN therefore appears as two groups of four digits, separated by a hyphen:
ISSN 0317-8471
ISSN 1050-124X
The check digit is always located in the extreme right (low order) position, and is calculated on a modulus 11 basis using weights 8 to 2.
Embedding ISSNs within the URN framework does not present encoding problems, since all of the characters that can appear in an ISSN (the 10 digits (0 to 9), the hyphen and capital letter X) are valid in the namespace-specific string (NSS) part of the URN. percent-encoding, as described in RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn], is never needed. In order to improve readability of the NSS, central hyphens SHOULD always be used.
Example: URN:ISSN:1234-1231
For URN resolution purposes, all elements, including the check digit and the central hyphen, must be taken into account.
If a local resource stores and manages ISSN without a central hyphen, it should be programmatically added for the constitution of URN:ISSN.
Applications, such as the national bibliography or the open archive of a university, can use the URN as the persistent address of the resource. There is just one place (the URN registry) where the address is mapped to one or more physical locations.
Persistence is one of the key features for any persistent identifier system. There are three inter-related aspects of persistence that need to be discussed: persistence of the resource itself, persistence of the identifier, and persistence of the URN-based resolvers.
Persistence of the resources : continuing resources are complex objects which evolve over time. In their (mostly) paper incarnations, they have been stored on library shelves sometimes for centuries. Bibliographic records mediate identification and access. If a continuing resource is available on print only, its URN:ISSN will resolve to the bibliographic record in the ISSN register.
The ISSN Register has indentified (at the beginning of 2012) almost 100,000 online continuing resources which may or may not have print equivalents. Furthermore, vast digitization efforts are now undertaken over the world to create electronic archives of printed continuing resources (these initiatives have often a dual aim of long term preservation and economies in shelving space); efforts are also under way to manage the long term preservation of online continuing resources.
All these efforts which have as a goal the persistence of the continuing resources will be all the more successful if they benefit from a standardized identification layer. This obviously also has an impact on the management of contents (volumes, issues, and first and foremost articles) where linking frameworks which appeared during the last ten years (CROSSREF or Open URL) make heavy use of the ISSN.
Persistence of the identifier : The ISSN as an identifier is persistent in the sense that once assigned, an ISSN will never be re-assigned to a different continuing resource.
Persistence of the resolvers : URN resolvers are not static. The services they'll supply will change over time, due to changes in technical infrastructure. For instance, new URN resolution services may be added or modified over time. Persistence of the resolvers themselves is mainly an organizational issue, related to the persistence of organizations maintaining them. As URN:ISSN resolution services will be based on the ISSN Register, which is itself a persistent resource which has been maintained for almost 35 years, we may thus assume that URN:ISSN resolution services will be persistent.
The ISSN Register will initially support four resolution services specified in RFC 2483 [RFC2483], namely I2L, I2Ls, I2C and I2Cs. Only I2C and I2Cs (URI to URC(s); delivery of descriptive metadata related to the resource) are valid for non-networked resources. Descriptive metadata can only be supplied in the MARC21 format.
Due to the structure of the ISSN, it is assumed that URN:ISSN resolution can only be reliably achieved through a central service, based on the ISSN Register which in turn can benefit from automated linking with other local resources using the ISSN as an identifier. Only a combination of the authority of the centralized ISSN Register and of local data can guarantee both reliability and persistence.
In the framework of URN:ISSN resolution, the ISSN-L is a very important new feature.
The ISSN-L (or "linking ISSN") is an important modification introduced in the latest revision of the ISSN standard in the ISO framework.
The ISSN-L has been defined to meet the need for a collocation, or grouping mechanism that brings together the various medium versions of a continuing resource, and thus facilitate content management.
The ISSN-L is an ISSN designated by the ISSN Network to group the different media versions of a continuing resource.
Only one ISSN-L is designated regardless of how many different medium versions of a continuing resource exist. A continuing resource will be associated with only one ISSN-L.
The designation of the ISSN-L is carried out either by a centre of the ISSN Network or is performed automatically as records are added to the ISSN Register. It is done either by those ISSN National Centres that are able to undertake this responsibility, or by the International Centre. The records produced by these National Centres include the ISSN-L in the ISSN records under their responsibility.
The first ISSN assigned, in the ISSN Register, to any medium version of a continuing resource is designated by default to function also as the ISSN-L and applies to all other media versions of that resource identified in the ISSN Register. An ISSN-L is designated for each continuing resource identified in the ISSN Register, even if the continuing resource is issued in only one medium. Only one ISSN-L is designated regardless of how many different medium versions of a continuing resource exist.
In the framework of URN:ISSN resolution, whether an ISSN is submitted as an ISSN-L or as an ISSN should be considered as having no practical impact as the response should always include by default basic resolution data for all ISSN which may be linked through a common ISSN-L.
For efficient practical resolution purposes, it should not be assumed that the requesting service has an unambiguous knowledge of either :
The URN:ISSN resolution service should make no such assumption concerning the knowledge of the requesting service. The URN:ISSN resolution should make available sufficient authoritative metadata so as to allow the requesting service to obtain the expected response, even if the ISSN submitted is not used fully adequately by the requestor. URN:ISSN resolution metadata should allow the requesting service to check and correct if necessary its potentially incorrect assumptions, so as to avoid the following situations :
Examples:
URN:ISSN:1234-1231 identifies the current print edition of "Medical News"
URN:ISSN:1560-1560 identifies the current online edition of "Medical News"
The ISSN-L linking both media versions of "Medical News" happens to be ISSN-L 1234-1231 (i.e based on the ISSN 1234-1231, designated as such in the framework of the management of the ISSN Register).
The resolution of URN:ISSN:1234-1231 should be equivalent to the resolution of URN:ISSN 1560-1560, i.e; in both cases one should find a reference to the other medium version.
As already indicated, continuing resources are complex objects or sets of objects which evolve over time and can be partly or fully duplicated, published, archived, remixed. Various entities (publishers, issuing bodies, libraries, content aggregators, archiving institutions, subscription services...) may be partly or fully responsible over time for the online management of these objects.
Their stewardship may be ambiguously implemented for various reasons :
In some cases, continuing resources are not processed or managed as such and only their constituent parts (for instance, volumes, issues, articles...) are made directly accessible as evolving sets.
Last but not least, commercial publications may restrict access to authenticated users only.
This practically means that "resolution" (in the sense of localization) of continuing resources can best be achieved in the framework of long term coordinated efforts, but cannot be guaranteed in all cases. The best results will of course be obtained with "preservation silos" or big entities. Concerning the "long tail" of small publications, preservation initiatives are best equipped to handle the link between identification and access to the resources themselves.
This means that URN:ISSN resolution will not be able to offer "full resolution" (i.e. reliable access to the resource itself) in all cases, even if the resource is "online".
On the other hand, URN:ISSN extended resolution services could be offered on a systematic basis thanks to the metadata stored in the ISSN Register and its potential linking with external resources, such as :
URN:ISSN resolution services can be both human readable and machine processable so as to support semantic web compatible services.
It should finally be noted that as the ISSN Register is a subscription based resource, URN:ISSN resolution cannot be a fully open service.
The formal URN Namespace Identifier Registration for the pre-2007 version of the International Standard Serial Number (ISSN) standard was done in "RFC 3044 [RFC3044].
The revised ISSN standard does not require a new namespace, but the registration is renewed here. The registrant organization has moved from a former address to a new one in Paris. Moreover, the description of the NSS and resolution details have been amended.
This registration describes how the International Standard Serial Number (ISSN) can be supported within the URN framework.
Namespace ID: ISSN
This Namespace ID has already been assigned to the International Standard Serial Number in January 2001 when the namespace was initially registered.
Registration Information:
Version: 2 Date: 2012-02-23
Declared registrant of the namespace:
Registering Organization: Centre international d'Enregistrement des Publications en Série - CIEPS-ISSN - ISSN International Centre
Designated Contact Person:
Name: Ms. Françoise Pellé
Affiliation: Director, ISSN International Centre
Email: issnic@issn.org
45 rue de Turbigo, 75003 PARIS, FRANCE
Web URL: <http://www.issn.org/ >
Declaration of syntactic structure of NSS part:
The ISSN syntax is as follows:
NNNN-NNNC
where N is a Digit character [0..9]
C is either a Digit character or letter "X" [0..9,X]
C is the check character
Example 1: URN:ISSN:1234-1231
Example 2: URN:ISSN: 0259-000X
Relevant ancillary documentation:
The ISSN (International Standard Serial Number) is a unique machine-readable identification number, which identifies unambiguously any continuing resource. This number is defined in ISO Standard 3297:2007. ISSNs have been in use for more than 30 years and they have deeply affected the handling of continuing resources and their contents. 88 countries are officially ISSN members (at the beginning of 2012).
The administration of the ISSN system is carried out at two levels: International Centre and National Centres.
The ISSN International Centre is located in Paris (France). The main functions of the Centre are:
Detailed information about ISSN usage can be found from the ISSN Users' Manual.
The manual is available at http://www.issn.org/2-23364-ISSN-Manual.php
Conformance with URN Syntax:
Legal ISSN characters are 0-9 and hyphen and X. No percent-encoding is needed. Hyphen carries no semantic content but SHOULD NOT be dropped from the NSS.
Rules for Lexical Equivalence of NSS part:
ISSN numbers are usually printed with the letters 'ISSN' and a single blank preceding the ISSN proper (for instance: ISSN 1234-1231). Any data preceding the ISSN MUST NOT be included in the NSS. No percent encoding is needed.
Prior to comparing the NSS of two ISSN-based URNs for equivalence, all hyphens, if present, MUST be removed and letter 'X' capitalized.
Note that, according to RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn], the prefix "URN:ISSN:" is case-insensitive; generic URI parsing and comparison software frequently uses lower case as the canonical (normalized) form.
The URNs are equivalent if the normalized forms obtained this way compare equal.
Identifier uniqueness and persistence considerations:
ISSN is a unique and persistent identifier. An ISSN, once it has been assigned, MUST NOT be re-used for another continuing resource. 'ISSN' URNs inherit the uniqueness and persistence properties from ISSNs.
Process of identifier assignment:
Assignment of ISSNs is controlled, and 'ISSN' URNs immediately inherit this property. There are three levels of control: the ISSN international Centre, national ISSN Centres, and finally all the stakeholders responsible for a correct use of the ISSN system.
Process for identifier resolution: See Section 4.3 of RFC3044.
Validation mechanism:
The check digit helps to assure the correctness of an ISSN number assigned for a continuing resource when it has been entered or processed. Applications processing bibliographic data such as integrated library systems MAY use the check digit to check the correctness of the ISSN string. If the number is found to be wrong due to, e.g., a typing error made by a publisher, the correct ISSN SHOULD nevertheless be used while the wrong number may be stored alongside for reference. Although the resource itself may only contain the wrong number, national bibliographies and systems used by relevant communities often will contain both the wrong and correct ISSN number.
Scope:
ISSN is a global identifier system used for identification of continuing resources. It is very widely used and supported by the publishing and scholarly publication communities.
This document proposes means of encoding ISSNs within the URN framework. An ISSN-based URN resolution service is depicted here, but in a generic level only; thus questions of secure or authenticated resolution mechanisms are excluded. It does not deal with means of validating the integrity or authenticating the source or provenance of URNs that contain ISSNs. Issues regarding intellectual property rights associated with objects identified by the ISSNs are also beyond the scope of this document.
Access control mechanisms may be implemented to limit access to some or all URN resolution services available in the URN Register. Such mechanisms, if any, will be discussed separately.
IANA is asked to update the existing registration of the Formal URN Namespace 'ISSN' using the template given above in Section 5.1, which follows the outline specified in RFC 3406bis [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg].
This draft is part of the URNBIS effort to revise the basic URN RFCs. The aim in the IETF is to bring these RFCs in alignment with the current URI Standard (STD 63, RFC 3986), ABNF, and IANA guidelines. The PERSID project http://www.persid.org/ is a significant impulse to this work.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. |
| [I-D.ietf-urnbis-rfc2141bis-urn] | Hoenes, A, "Uniform Resource Name (URN) Syntax", Internet-Draft draft-ietf-urnbis-rfc2141bis-urn-01, October 2011. |
| [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg] | Hoenes, A, "Uniform Resource Name (URN) Namespace Definition Mechanisms", Internet-Draft draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01, October 2011. |