Network Working Group J. Goodwin Internet-Draft ISO Intended status: Standards Track December 06, 2006 Expires: June 9, 2007 A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO) draft-goodwin-iso-urn-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 9, 2007. Copyright Notice Copyright (C) The IETF Trust (2006). Goodwin Expires June 9, 2007 [Page 1] Internet-Draft ISO URN Schema December 2006 Abstract This document describes a Uniform Resource Name Namespace Identification (URN NID) for the International Organization for Standardization (ISO). This URN NID is intended for use for the identification of persistent resources published by the ISO standards body (including documents, document metadata, extracted resources such as standard schemata and standard value sets, and other resources). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Specification Template . . . . . . . . . . . . . . . . . . . . 5 2.1. Namespace ID . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Registration Information . . . . . . . . . . . . . . . . . 5 2.3. Declared registrant of the namespace . . . . . . . . . . . 5 2.4. Declaration of structure . . . . . . . . . . . . . . . . . 5 2.4.1. Definition . . . . . . . . . . . . . . . . . . . . . . 5 2.4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Relevant ancillary documentation . . . . . . . . . . . . . 15 2.6. Identifier uniqueness considerations . . . . . . . . . . . 16 2.7. Identifier persistence considerations . . . . . . . . . . 16 2.8. Process for identifier resolution . . . . . . . . . . . . 16 2.9. Rules for lexical equivalence . . . . . . . . . . . . . . 17 2.10. Conformance with URN Syntax . . . . . . . . . . . . . . . 17 2.11. Validation mechanism . . . . . . . . . . . . . . . . . . . 17 2.12. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3. Namespace Considerations . . . . . . . . . . . . . . . . . . . 18 4. Community Considerations . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 7.2. Informative References . . . . . . . . . . . . . . . . . . 24 Appendix A. Alternative naming schemes . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Goodwin Expires June 9, 2007 [Page 2] Internet-Draft ISO URN Schema December 2006 1. Introduction The International Organization for Standardization (ISO) was created by international agreement in 1947. ISO is a network of the national standards institutes of many countries, on the basis of one member per country, with a Central Secretariat in Geneva, Switzerland, that coordinates the system. ISO acts as a bridging organization in which a consensus can be reached on solutions that meet both the requirements of business and the broader needs of society, such as the needs of stakeholder groups like consumers and users. (Further information is provided at http://www.iso.org/iso/en/aboutiso/introduction/index.html.) The core mission of ISO is to develop technical standards constituting technical agreements which provide the framework for compatible technology worldwide. ISO standards contribute to making the development, manufacturing and supply of products and services more efficient, safer and cleaner. They make trade between countries easier and fairer. Every participating ISO member institute (full members) has the right to take part in the development of any standard which it judges to be important to its country's economy. No matter what the size or strength of that economy, each participating member in ISO has one vote. ISO's activities are thus carried out in a democratic framework where each country is on an equal footing to influence the direction of ISO's work at the strategic level, as well as the technical content of its individual standards. Although ISO standards are voluntary, the fact that they are developed in response to market demand, and are based on consensus among the interested parties, ensures widespread applicability of the standards. Consensus, like technology, evolves and ISO takes account both of evolving technology and of evolving interests by requiring a review of its standards at least every five years to decide whether they should be maintained, updated or withdrawn. ISO publishes International Standards and other technical specifications that are cited in the definitions of required or expected practices in many industries in many nations. These specifications contain dictionaries of standard terms, catalogues of reference values, definitions of formal languages, formal schemata for information capture and exchange, specifications for standard practices, and other information resources of general use to international trade and industry. ISO wishes to create and manage globally unique, persistent, location-independent identifiers for these resources. Goodwin Expires June 9, 2007 [Page 3] Internet-Draft ISO URN Schema December 2006 This specification defines the syntax for URNs that identify documents developed by the International Organization for Standardization (ISO) in accordance with the standards development procedures defined in the ISO/IEC Directives, Part 1 [ISODIR-1] and the ISO supplement [ISODIR-S] and processed by the ISO Central Secretariat. The syntax extends to identify document metadata and resources related to these documents or otherwise associated with them. It does not extend to products derived from these documents and published by ISO (e.g. handbooks, compendia) or documents at or below the Technical Committee level. Revisions of this specification may define syntax for URNs in this namespace that identify other ISO objects, when the ISO community defines a requirement for such identifiers. Goodwin Expires June 9, 2007 [Page 4] Internet-Draft ISO URN Schema December 2006 2. Specification Template 2.1. Namespace ID "iso" 2.2. Registration Information Version 1.6 Date: 2006-12-06 2.3. Declared registrant of the namespace J. Goodwin ISO Central Secretariat International Organization for Standardization (ISO) Case Postale 56 CH-1211 Geneva 20 Switzerland E-mail: goodwin@iso.org 2.4. Declaration of structure 2.4.1. Definition The Namespace Specific Strings (NSS) of all URNs assigned by ISO will conform to the syntax defined in section 2.2 of [RFC2141]. The NSS has the following ABNF [RFC4234] specification: NSS = std-nss All URNs conforming to this specification begin the NSS with the prefix "std:", to denote the restriction to documents developed by the ISO standards development procedures as defined in the ISO/IEC Directives, Part 1 [ISODIR-1] and the ISO Supplement [ISODIR-S]. Prefixes that identify ISO objects of other kinds may be defined in future revisions of this specification. std-nss = "std:" docidentifier *supplements *docelement [additions] The prefix "std:" distinguishes an "std-nss". An std-nss identifies the ISO document that is designated by the "docidentifier", as extended or modified by any identified "supplements". (An std-nss that identifies all parts of a multipart ISO document is a special case as described under the Goodwin Expires June 9, 2007 [Page 5] Internet-Draft ISO URN Schema December 2006 element "partnumber".) If the std-nss contains an "additions" element, the NSS identifies a resource extracted from the ISO document or otherwise associated with it (see below). docidentifier = originator [":" type] ":" docnumber [":" partnumber] [[":" status] ":" edition] [":" docversion] [":" language] "docidentifier" provides the complete identification of an ISO document. Each of its component elements is described below. originator = "iso" / "iso-iec" / "iso-cie" / "iso-astm" / "iso-ieee" / "iec" "originator" is the organization (usually an international body) from which a document emanates. Current values: iso = International Organization for Standardization iec = International Electrotechnical Commission (IEC), or Commission internationale electrotechnique (CIE) iso-iec = jointly developed by ISO and IEC iso-cie = jointly developed by ISO and the Commission internationale d'eclairage (CEI) iso-astm = jointly developed by ISO and the American Society for Testing and Materials International (ASTM) iso-ieee = jointly developed by ISO and the Institute for Electrical and Electronics Engineers (IEEE) Revisions of this specification may define additional values. type = "data" / "guide" / "isp" / "iwa" / "pas" / "r" / "tr" / "ts" / "tta" "type" designates the ISO deliverable type. If the "type" element is not present, the classification is "international standard". Other current values: data = Data (document type no longer published) Goodwin Expires June 9, 2007 [Page 6] Internet-Draft ISO URN Schema December 2006 guide = Guide isp = International Standardized Profile iwa = International Workshop Agreement pas = Publicly Available Specification r = Recommendation (document type no longer published) tr = Technical Report ts = Technical Specification tta = Technology Trends Assessment docnumber = DIGITS "docnumber" is the reference number assigned to the document by ISO and/or IEC. An ISO document may comprise a single document, or two or more separate parts each of which is identified by "partnumber". partnumber = "-" 1*( DIGIT / ALPHA / "-" ) "partnumber" is the reference number that identifies a part of a multipart standard. Where it is required to refer to a multipart ISO document in its entirety, this can be designated by omitting the "partnumber" element. However, this precludes the possibility of using any further elements except "additions". _NOTE_ The option to refer to a multipart ISO document by omitting the "partnumber" element has been included to align with the provision in the ISO/IEC Directives, Part 2, 2004 [ISODIR-2] subclause 6.2.2 of making an undated reference to all parts of an ISO document. It is only permissible to use this option where the URN is referring to a multipart ISO document in its entirety. Since the use of this option precludes the designation of the elements "status" and "edition", it is implicit that the URN needs to remain valid irrespective of any future changes to the multipart document (see the rules for undated references given in the ISO/IEC Directives, Part 2, 2004 [ISODIR-2] subclause 6.6.7.5.2). This shall be taken into consideration in the use (and maintenance) of any URN specification employing this option. Goodwin Expires June 9, 2007 [Page 7] Internet-Draft ISO URN Schema December 2006 _NOTE_ In the case where the multipart document comprises different types of ISO deliverable, the "type" of the core part (usually part 1) applies. See the example "Reference to a resource related to all parts of a multipart document". Except for the case where it is required to refer to a multipart document in its entirety, the element "partnumber" is required if the identified resource is a part of an ISO document. Otherwise, this element is not used. status = ( "draft" / "cancelled" ) / stage "status" indicates the publication status of the document. When the "status" element is not present, the NSS refers to a published document. Other values: draft = document that has not yet been accepted for publication by international ballot cancelled = document that has been deleted or withdrawn stage = "stage-" stagecode ["." iteration] "stage" indicates the stage code and iteration of the document. stagecode = DIGIT DIGIT "." DIGIT DIGIT "stagecode" is the harmonized stage code in accordance with ISO Guide 69:1999, "Harmonized Stage Code system (Edition 2) -- Principles and guidelines for use" [ISOGUIDE69]. iteration = "v" DIGITS "iteration" is a sequential number which refers to a specific iteration of the project's lifecycle through the designated stage If no "iteration" is specified the reference is to the highest iteration available for the specified stagecode. _NOTE_ In the ISO Central Secretariat project management database the "iteration" is referred to as the "project version". edition = "ed-" DIGITS "edition" designates a specific edition of the document. (DIGITS is the (sequential) edition number.) If no "edition" is specified, the NSS refers to the latest edition. Goodwin Expires June 9, 2007 [Page 8] Internet-Draft ISO URN Schema December 2006 docversion = "v" (simpleversion / isoversion) simpleversion = DIGITS "docversion" designates the version number of a document's "edition". It is altered by correction (corrected version; Technical Corrigendum) or amendment (Amendment; Addendum) and is distinct from a revision, which changes the edition number. In the "simpleversion", the first version published is "1", and each subsequent correction or amendment increases the version number by 1. If no "docversion" is specified, the reference is to the highest version number available for the denoted "edition". Current values of "simpleversion": 1 - first version published 2 - corrected version published isoversion = baseversion *includedsuppl baseversion = DIGITS includedsuppl = "-" suppltype supplnumber [ "." supplversion ] An "isoversion" can be linked to a simpleversion by defining an existing simpleversion as baseversion and listing all the "supplements" (corrections and amendments) incorporated into that version. Examples for the "isoversion" (internal ISO version) scheme: 1 = first version of standard 1-amd1.v1 = first version of standard incorporating first version of Amendment 1 1-amd1.v1-amd2.v1 = first version of standard incorporating first version of Amendment 1 and first version of Amendment 2 1-amd1.v2-amd2.v1-amd3 = first version of standard incorporating corrected version of Amendment 1, first version of Amendment 2, and highest version of Amendment 3 Goodwin Expires June 9, 2007 [Page 9] Internet-Draft ISO URN Schema December 2006 1-cor3 = first version of standard incorporating highest version of Technical Corrigendum 3 1-amd1-cor3 = first version of standard incorporating highest version of Amendment 1 and highest version of Technical Corrigendum 3 language = monolingual / bilingual / trilingual monolingual = "en" / "fr" / "ru" / "es" / "ar" bilingual = "en-fr" / "en-ru" / "fr-ru" trilingual = "en-fr-ru" "language" designates the official ISO language(s), or the language of an official translation, in which the document (object) is processed and published by ISO (excluding languages which constitute only specific elements of the content). The value is one or more alpha-2 codes, each of which designates a language, as specified in ISO 639-1 [ISO639-1]. If no language element is specified, "en" is assumed. supplements = ":" suppltype ":" supplnumber [":" supplversion ] [":" language ] suppltype = "amd" / "cor" / "add" supplnumber = DIGITS supplversion = "v" DIGITS "supplements" designate technical alterations of or additions to an ISO standard that do not result in a new "edition" or "version". Supplements are of three types, designated by "suppltype": amd = Amendment -- a document that alters and/or adds to previously agreed technical provisions in an existing ISO document; an amendment is subject to acceptance by ballot in accordance with the ISO/IEC Directives, Part 1, 2004 [ISODIR-1] subclause 2.10.3 cor = Technical Corrigendum -- a document that corrects a technical error or ambiguity, or updates the ISO document in such a way that the modification has no effect on the technical normative elements; a Technical Corrigendum is not balloted -- see the ISO/IEC Directives, Part 1, 2004 Goodwin Expires June 9, 2007 [Page 10] Internet-Draft ISO URN Schema December 2006 [ISODIR-1] subclause 2.10.2 add = Addendum -- (document type no longer published) Addenda were documents that changed (by correction, addition or deletion) the technical requirements of an ISO document; an addendum was subject to acceptance by ballot in accordance with the ISO/IEC Directives, Part 1. (Addenda are included in this RFC because some of them are still valid.) Supplements are numbered consecutively per ISO document, and within each supplement type. "supplnumber" identifies the number of the supplement. "supplversion" designates the version of a published supplement. At present only two versions are used in practice: when a supplement is published it is a version 1. If that supplement is subsequently corrected by issuing a corrected version, as designated by the term "Corrected" on the cover page together with a date, the corrected version is version 2. The language of a supplement can be different from that of the document. For example, a supplement may apply to only one of the languages of a bilingual document. For such cases, the language of a supplement can be identified using the "language" element defined above. The interpretation is the same, except that it applies only to the supplement. docelement = clause / term clause = ":clause:" clauseno / clauserange *( "," clauseno / clauserange ) clauseno = ( ALPHA / DIGITS ) *( "." DIGITS ) clauserange = clauseno "-" clauseno term = ":term:" termno / termrange *( "," termno / termrange) termno = ( ALPHA / DIGITS ) *( "." DIGITS ) termrange = termno "-" termno "docelement" identifies one or more numbered subdivisions of a document. Types of numbered subdivision are specified in the ISO/ IEC Directives, Part 2 [ISODIR-2]. This RFC currently specifies forms for reference to terms and clauses only. Revisions of this Goodwin Expires June 9, 2007 [Page 11] Internet-Draft ISO URN Schema December 2006 specification may define additional values. "clause" represents the selection of one or more clauses or subclauses of the specification. The form "clauseno HYPHEN clauseno" designates a range of (sub)clauses and the form "clauseno COMMA clauseno" a list. A list can contain ranges. "clauseno" designates one clause or subclause in a specification. When the first character of a "clauseno" is a digit, the reference is to the clause designated by that digit string, and to the subclause designated by any additional digit strings separated by periods. When the first character of a "clauseno" is alphabetical, the reference is to the corresponding Annex, and to the (sub)clauses designated by additional digit strings. "term" represents the selection of one or more consecutive terms of the specification. The form "termno HYPHEN termno" designates a range of terms and the form "termno COMMA termno" a list. A list can contain ranges. "termno" designates one term in a specification. When the first character of a "termno" is a digit, the reference is to the term designated by that digit string and by any additional digit strings separated by periods. When the first character of a "termno" is alphabetical, the reference is to the corresponding Annex, and to the terms designated by additional digit strings. additions = techdefined / isodefined techdefined = ":tech" *techelement techelement = ; unspecified isodefined = ; unspecified "additions" are additional elements of the NSS intended to identify a representation of an ISO document, an extract from an ISO document, or some related information set, as a resource in its own right. "techdefined" represents an associated or embedded resource defined by the committee that develops or maintains the identified document. All such "additions" begin with the keyword "tech", but the further syntax is defined by the committee. "isodefined" represents associated or embedded resources defined by the ISO Central Secretariat. The definition of "additions" beginning with any symbol other than "tech" is reserved to the ISO Goodwin Expires June 9, 2007 [Page 12] Internet-Draft ISO URN Schema December 2006 Central Secretariat. The syntax of these additions is not specified in this RFC. Specific syntax for these additions will be specified as needed by the ISO Central Secretariat, or by the individual Committee that has the responsibility for developing or maintaining the identified document. (See further discussion under Process for Identifier Resolution below.) DIGITS = DIGIT *DIGIT DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" ALPHA = "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" Basics of the ABNF notation used : " " literals (terminal character strings); terms not in quotes are non-terminals / alternatives [] indicates an optional rule () indicates a sequence group, used as a single alternative or as a single repeating group * indicates that the following term or group can repeat at least and at most times; default values are 0 and infinity respectively ; comment 2.4.2. Examples o Language handling: urn:iso:std:iso:9999:-1:ed-1:en refers to the 1st edition of ISO 9999-1, in English urn:iso:std:iso:9999:-1:ed-1:en-fr refers to the 1st edition of ISO 9999-1, in English/French (bilingual document) Goodwin Expires June 9, 2007 [Page 13] Internet-Draft ISO URN Schema December 2006 o Originators/document type: urn:iso:std:iso-iec:tr:9999:-1:ed-1:en refers to the 1st edition of ISO/IEC TR 9999-1, in English o Status: urn:iso:std:iso-iec:9075:-3:cancelled:ed-2:en urn:iso:std:iso-iec:9075:-3:stage-95.99:ed-2:en both refer to the cancelled 2nd edition of ISO/IEC 9075-3, in English urn:iso:std:iso-iec:9075:-3:draft:ed-4:en urn:iso:std:iso-iec:9075:-3:stage-30.60:ed-4:en both refer to the draft 4th edition of ISO/IEC 9075-3, in English urn:iso:std:iso:128:-20:en urn:iso:std:iso:128:-20:stage-90.20:ed-1:en both refer to the published (90.20 = under 2nd periodic review) 1st edition of ISO 128-20, in English urn:iso:std:iso:128:-71:cancelled:ed-1:en urn:iso:std:iso:128:-71:stage-30.98.v2:ed-1:en both refer to the cancelled (30.98 = project deleted) 1st edition of ISO 128-71, in English; the second example refers specifically to the 2nd iteration (projectversion) at stage 30 o Non-numeric part number: urn:iso:std:iso:9999:-A02:ed-1:en refers to the 1st edition of ISO 9999-A02, in English o Reference to a resource related to all parts of a multipart document: urn:iso:std:iso:20022:tech:xsd:camt.001.001.01 refers to a "techdefined" resource (i.e. a resource defined by the committee that develops or maintains the identified document) associated with ISO 20022 in its entirety; in this example the techdefined part comprises ":xsd:camt.001.001.01" _NOTE_ At the time of drafting of this schema, ISO 20022 comprises 5 parts: parts 1 and 2 are International Standards; parts 3 to 5 are Technical Specifications. Therefore the "doctype" standard is used in the URN. o Docversion handling: Goodwin Expires June 9, 2007 [Page 14] Internet-Draft ISO URN Schema December 2006 urn:iso:std:iso:9999:-1:ed-1:v2:en refers to the corrected English version of 1st edition of ISO 9999-1 urn:iso:std:iso:9999:-1:ed-1:v1-amd1:en refers to the version comprising 1st edition of ISO 9999-1, incorporating the latest version of Amendment 1, in English urn:iso:std:iso:9999:-1:ed-1:v1:en-fr:amd:1:v2:en refers to the 2nd version of Amendment 1, in English, which amends the 1st version of edition 1 of ISO 9999-1, in English/French (bilingual document) urn:iso:std:iso:9999:-1:ed-1:v1-amd1.v1:en-fr:amd:2:v2:en (isoversion scheme) refers to the corrected version of Amendment 2, in English, which amends the document comprising the 1st version of edition 1 of ISO 9999-1 incorporating the 1st version of Amendment 1, in English/ French (bilingual document) urn:iso:std:iso:5817:ed-2:v2:en:cor:1:en refers to the 1st version of Technical Corrigendum 1, in English, which amends the corrected version of edition 2 of ISO 5817, in English o Supplement handling: urn:iso:std:iso:9999:-1:ed-2:en:amd:1 refers to Amendment 1 to 2nd edition of ISO 9999-1, in English urn:iso:std:iso:9999:-1:ed-2:en:amd:1:v2 refers to corrected version of Amendment 1 to 2nd edition of ISO 9999-1, in English urn:iso:std:iso:9999:1:ed-2:en-fr:amd:2:en refers to Amendment 2 in English to 2nd edition of ISO 9999-1, in English/French (bilingual document) urn:iso:std:iso:9999:-1:ed-2:en:amd:1:cor:1 refers to Corrigendum 1 to Amendment 1 to 2nd edition of ISO 9999-1, in English 2.5. Relevant ancillary documentation ISO/IEC Directives, Part 1 [ISODIR-1] and Part 2 [ISODIR-2], and ISO supplement [ISODIR-S]. Goodwin Expires June 9, 2007 [Page 15] Internet-Draft ISO URN Schema December 2006 2.6. Identifier uniqueness considerations Assignment of URNs for documents in the requested namespace will be managed by the ISO Central Secretariat, which will ensure that the assigned URNs are consistent with the ISO Directives for unique identification of ISO documents. Assignment of URNs for Technical Committee resources related to ISO documents will be managed by the Technical Committees developing or maintaining those documents. As indicated above, each such URN will extend the URN for the containing document via "additions". The responsibility of the Technical Committee will therefore be to ensure the uniqueness of the techdefined "addition" that constitutes the identifier for the resource within the document namespace, and thus the uniqueness of the overall resource identifier within the requested namespace. 2.7. Identifier persistence considerations Assigned URNs will not be reused and will remain valid beyond the lifecycle of the referenced resources. However, it should be noted that although the URNs remain valid, the status of the referenced resource may change. 2.8. Process for identifier resolution Resolving document identifiers: This schema has been developed with the intent that a URN identifying an ISO document can be transformed to a valid http URI by replacing the requested URN namespace prefix ("iso") and the "std:" prefix with the domain name "standards.iso.org" and replacing all occurrences of ":" within the identifier with "/". (ISO is planning to develop a website implementation to support these URIs.) Examples: urn:iso:std:iso:9999:-1:ed-1:en: corresponds to: http://standards.iso.org/iso/9999/-1/ed-1/en/ urn:iso:std:iso-iec:tr:9999:-1:ed-1:en: corresponds to: http://standards.iso.org/iso-iec/tr/9999/-1/ed-1/en/ urn:iso:std:iso:9999:-1:ed-2:en-fr:amd:2: corresponds to: http://standards.iso.org/iso/9999/-1/ed-2/en-fr/amd/2/ Resolving identifiers for "addition" resources: Goodwin Expires June 9, 2007 [Page 16] Internet-Draft ISO URN Schema December 2006 For URNs in the requested namespace that refer to additional resources related to ISO documents, the ISO Central Secretariat will specify the resolution procedure at the time it defines the syntax for the corresponding "addition" to the NSS. In most cases, those resources will be maintained on an ISO website, as extensions to the HTTP URIs described above. 2.9. Rules for lexical equivalence URNs are lexically equivalent if and only if they are lexically identical. The "case" of alphabetic characters in "part" elements is specified to be "upper case", in order to avoid ambiguity with other elements that may follow a docnumber, have similar representations, and begin with "lower case" alphabetics. 2.10. Conformance with URN Syntax No special considerations. 2.11. Validation mechanism None specified. 2.12. Scope Global. Goodwin Expires June 9, 2007 [Page 17] Internet-Draft ISO URN Schema December 2006 3. Namespace Considerations The ISO specific requirements are as follows: o globally unique, persistent identifiers o location-independent identifiers o human-interpretable identifiers o a scheme applicable to paper documents as well as machine-readable documents o a scheme applicable to conceptual documents and explicit forms of documents o a scheme applicable to resources extracted from documents o a scheme applicable to "metadata" associated with documents o a scheme in which the identifier assignment is managed by the ISO Central Secretariat. Location-independence: Because the publication of ISO standards is a complex arrangement involving multiple development organizations and national standards institutes, a given ISO document may be available in a number of forms from a number of sources. This makes it important to have a document identifier that is global in scope, widely and uniformly used, and independent of the text source used by any given reference. Human-interpretable: Many, perhaps most, references to documents appear in text generated by human authors. It is important that an author familiar with the scheme be able to generate a correct URN for a document for which s/he has the ISO reference (or document identifier). Conversely, it is important that a reader unfamiliar with the scheme be able to identify the URN as a reference to an ISO document, particularly an ISO standard, and also to recognize identifiers for forms, languages, or metadata sets. Paper documents: Older ISO standards that are commonly used as industrial references exist only in paper form or in earlier machine- readable forms that are not commonly used on the Internet. It is important to have a document identifier scheme that extends to these resources as well. (In fact, many of these have been converted to Internet forms, and others are being converted, but it is important that the identifier be independent of the form in which the document can be obtained at any given time.) Goodwin Expires June 9, 2007 [Page 18] Internet-Draft ISO URN Schema December 2006 Conceptual documents vs. representation forms: Because ISO documents are regularly maintained and re-published in multiple forms, it is important to have document identifiers that denote the conceptual document, without regard to publication form. At the same time, it is necessary for certain types of use to be able to refer to specific editions, or specific publication forms (for example, editions in different languages, or to PDF or HTML versions). This URN specification allows for the identification of these different types of use in the "isodefined" part of the "additions" element. Document extracts: ISO standards may contain formal specifications in machine-processable languages, or formal specifications that also have representations in machine-processable languages. It is useful to be able to extract these specifications in machine-processable form as separate resources, and therefore it is necessary to give these "extracted resources" global identifiers derived from the document identifier using a consistent identification scheme. Document metadata: Certain uses of documents and document text, primarily bibiliographic, also extract information from the documents, and that information, commonly called "metadata", is organized in machine-readable forms conforming to other standards. These metadata sets then become resources in their own right. It is important to give them URN identifiers consistent with the document identification scheme. Goodwin Expires June 9, 2007 [Page 19] Internet-Draft ISO URN Schema December 2006 4. Community Considerations The ISO community is broad in two dimensions. In one dimension, its documents are developed and used in a large variety of industries and professions: natural sciences, manufacturing, construction, transportation, information technology, social sciences, etc. In the other dimension, it is a community of expert developers, standards managers, publishers, professional users and consumers. And Internet information technologies are a part of common professional practice in all of these areas in both dimensions. ISO standards are cited in business agreements, in professional publications, in product descriptions, and in standards development and publication activities. When these citations appear in electronic form, the references must be unambiguous. The information technology community is itself very active in the development and use of standards, and many ISO publications are developed by and for that community. When an Internet information exchange uses a form specified in an ISO document, or a terminology defined in an ISO document, it is often necessary to identify that ISO specification in the envelope surrounding the exchange. That identification should use a formal unambiguous identifier in a form readily recognized by the receiving software, and possibly by the ultimate human recipient of the information. In order to facilitate the use of existing and emerging Internet technologies for all of these purposes, URNs conforming to IETF RFC 2141 represent the most useful form of formal globally unambiguous identifier. The use of a managed namespace for such identifiers, following a consistent scheme for identifying ISO documents and their derivatives would be of significant benefit to the entire ISO community. It would give professional users in many industries a standard form for electronic reference to ISO standards in HTML, XML, PDF, etc., documents. It would give software developers a standard form for reference to ISO standard protocols, schemata, languages, data sets, etc. It would give standards developers a standard form for reference to other ISO publications in various stages of development. And it would give them a standard form for creating identifiers for machine-readable information sets contained in, or derived from, the specifications. Goodwin Expires June 9, 2007 [Page 20] Internet-Draft ISO URN Schema December 2006 It would give standards managers and publishers a formal uniform scheme for reference to specific publications, editions and versions of ISO documents. While the assignment of identifiers under this scheme is managed by the ISO Central Secretariat, the processes by which the identified objects arise and acquire such identifiers are the result of agreements made by the member bodies. Every such project is initiated by one member body and reviewed and voted on by the others. Every accepted project is open to participation by any member body, and in fact, participation by a certain minimum number (usually 5) of member bodies is required for acceptance of most projects. In general, the member bodies are open professional and industrial organizations reflecting broad expertise and national interest. It should be noted that ISO documents in draft state are not usually made available outside the ISO standards development community. Making them available to professionals outside of the process might well mislead the recipients into premature adoption of practices that are not yet completely specified or have not yet achieved consensus, and therefore may well change. It should also be noted that ISO documents are not, in general, freely available over the Internet. Rather there are complex agreements between ISO and its member institutes as to the rights to the publications and the corresponding fees that may be charged for paper or electronic copies of various editions. Some ISO documents are freely available, and some are freely available in certain forms. In general, derivatives of ISO documents (schemata, metadata sets, etc.) are freely available over the Internet in the appropriate machine-readable forms. A URL associated with a URN in the requested namespace may therefore lead directly to a machine-readable copy of the text of the document or derivative, or it may lead to a site that can provide that text for a fee, or it may lead to a site that can only sell a paper copy of the document. Bearing in mind that ISO is a network of otherwise independent institutes, this behaviour is simply a property of the ISO community. Finally, it should be noted that, for many purposes, reference to the ISO standard is what is required, and only the product engineer or software tool builder actually needs access to the text. This request is based on the need to standardize the form of reference, not the means of access. Goodwin Expires June 9, 2007 [Page 21] Internet-Draft ISO URN Schema December 2006 5. IANA Considerations IANA is requested to assign a formal NID. The ISO Central Secretariat will maintain a registry of the permissible values for the elements comprising the NSS. Information may be obtained from the following address: urn@iso.org. Goodwin Expires June 9, 2007 [Page 22] Internet-Draft ISO URN Schema December 2006 6. Security Considerations The ISO URN Namespace ID shares the security considerations outlined in [RFC3406], but has no other known security considerations. Goodwin Expires June 9, 2007 [Page 23] Internet-Draft ISO URN Schema December 2006 7. References 7.1. Normative References [ISODIR-1] International Organization for Standardization, "Procedures for the technical work", ISO/IEC Directives Part 1, Edition 5, 2004. [ISODIR-2] International Organization for Standardization, "Rules for the structure and drafting of International Standards", ISO/IEC Directives Part 2, Edition 5, 2004. [ISODIR-S] International Organization for Standardization, "Procedures specific to ISO", ISO/IEC Directives Supplement. [ISOGUIDE69] International Organization for Standardization, "Harmonized Stage Code system (Edition 2) - Principles and guidelines for use.", ISO Guide 69:1999. [ISO639-1] International Organization for Standardization, "Codes for the representation of names of languages - Part 1: Alpha-2 code", ISO 639-1:2002. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. 7.2. Informative References [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061, February 2001. [RFC3151] Walsh, N., Cowan, J., and P. Grosso, "A URN Namespace for Public Identifiers", RFC 3151, August 2001. Goodwin Expires June 9, 2007 [Page 24] Internet-Draft ISO URN Schema December 2006 Appendix A. Alternative naming schemes Before initiating this request, ISO attempted to find an existing or currently proposed URN NID scheme that might be used instead of a dedicated scheme. Two existing schemes were carefully considered, because they clearly meet part of the requirements: o The OID scheme, documented in [RFC3061] o The PublicId scheme, documented in [RFC3151] The OID scheme is derived from the joint ISO/ITU-T ASN.1 object- identifier scheme specified in ISO/IEC 8824-1:2002 (original edition 1984; [RFC3061] cites the 1988 CCITT edition of the encoding rules in ISO/IEC 8825). This standard assigned to ISO the registry authority for all identifiers in the { iso(1) } namespace, and therefore, ISO controls the registry of all identifiers beginning "oid:1:". And in fact, ISO has developed, and is using, an identification scheme under ASN.1 that meets most of the above requirements. ISO could clearly define a use of the OID scheme that would be adequate to meet all of its technical objectives, although it would further complicate the current ASN.1 scheme. The original intent of ISO 8824 was to permit both a human-readable form for the identifier, to maximize intuitive recognition, and an encoding that minimized the number of bits needed to communicate an OID value over a network. Regrettably, the encoding chosen in RFC 3061 is much closer to the minimal bits encoding than to the human- readable one. The NSS for the OID scheme consists entirely of digits and punctuation. For example, the ASN.1 identifier { iso(1) standard(0) 7852 part(2) edition(3) } becomes: urn:oid:1:0:7852:2:3. This is difficult for a human reader or author to interpret. It is also easy to mistype, and the scheme contains no "check-digits", which makes it difficult to validate, leading to the propagation of URNS that are invalid or valid but erroneous. Finally, the all- numeric form conveys no hint of the name of the responsible organization and therefore no hint of any URL that might aid a human reader in interpreting the reference. The OID scheme makes all of the required identifiers technically possible and technically useable by software, but for all practical purposes, the OID URNs are useful only to software. The PublicId scheme is derived from SGML (ISO 8879:1986 and ISO 9070: 1991) bibliographic catalogue forms. Narrowed to ISO publications, it is adequate for the unique global persistent identification of published documents, in both paper and machine-processable form. Goodwin Expires June 9, 2007 [Page 25] Internet-Draft ISO URN Schema December 2006 Importantly, the PublicId scheme does not have a "conceptual document" notion -- it identifies specific publications and editions. "Weak identification" could be used to implement the conceptual document concept, but the PublicId scheme does not document that interpretation. And in any case, the PublicId scheme does not extend to draft documents, which are often referenced in pilot implementations, to separate forms of a document, or to resources extracted from documents. It supports only those metadata elements that are defined in SGML. The scheme could be extended to do most of these, but the ISO-specific extensions would not in general extend to the much broader base of documents identified by PublicIds. (Version and edition management practices vary significantly across publishers, depending on their milieu.) Further, ISO Central Secretariat could not and should not control the registry of such URNs. ISO therefore concluded that the alternative schemes are not adequate to meet the requirements of the ISO community. Whilst requesting a new namespace for ISO documents and their derivatives, ISO does not wish to discourage the use of these other identifiers for ISO publications. The PublicId form, in particular, is useful for referring to ISO publications in a larger bibliographic information space. Goodwin Expires June 9, 2007 [Page 26] Internet-Draft ISO URN Schema December 2006 Author's Address J. Goodwin International Organization for Standardization Case Postal 56 Geneva 20 1211 Switzerland Email: goodwin@iso.org URI: http://www.iso.org Goodwin Expires June 9, 2007 [Page 27] Internet-Draft ISO URN Schema December 2006 Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Goodwin Expires June 9, 2007 [Page 28]