From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5141.txt | 1571 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1571 insertions(+) create mode 100644 doc/rfc/rfc5141.txt (limited to 'doc/rfc/rfc5141.txt') diff --git a/doc/rfc/rfc5141.txt b/doc/rfc/rfc5141.txt new file mode 100644 index 0000000..1681d68 --- /dev/null +++ b/doc/rfc/rfc5141.txt @@ -0,0 +1,1571 @@ + + + + + + +Network Working Group J. Goodwin +Request for Comments: 5141 H. Apel +Category: Informational ISO + March 2008 + + + A Uniform Resource Name (URN) Namespace for + the International Organization for Standardization (ISO) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +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). + + + + + + + + + + + + + + + + + + + + + + + + + + + +Goodwin & Apel Informational [Page 1] + +RFC 5141 ISO URN Schema March 2008 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Specification Template ..........................................4 + 2.1. Namespace ID ...............................................4 + 2.2. Registration Information ...................................4 + 2.3. Declared Registrant of the Namespace .......................4 + 2.4. Declaration of Structure ...................................4 + 2.4.1. Definition ..........................................4 + 2.4.2. Examples ...........................................12 + 2.5. Relevant Ancillary Documentation ..........................15 + 2.6. Identifier Uniqueness Considerations ......................15 + 2.7. Identifier Persistence Considerations .....................15 + 2.8. Process for Identifier Resolution .........................16 + 2.9. Rules for Lexical Equivalence .............................16 + 2.10. Conformance with URN Syntax ..............................17 + 2.11. Validation Mechanism .....................................17 + 2.12. Scope ....................................................17 + 3. Namespace Considerations .......................................17 + 4. Community Considerations .......................................18 + 5. IANA Considerations ............................................20 + 6. Security Considerations ........................................20 + 7. References .....................................................21 + 7.1. Normative References ......................................21 + 7.2. Informative References ....................................21 + Appendix A. Alternative Naming Schemes ............................23 + Appendix B. ABNF Definition of Namespace ID = "iso" + (Informative) .........................................24 + +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/about.htm. + + The core mission of ISO is to develop technical standards + constituting technical agreements that 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. + + + +Goodwin & Apel Informational [Page 2] + +RFC 5141 ISO URN Schema March 2008 + + + Every participating ISO member institute (full members) has the right + to take part in the development of any standard that 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 the 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 of both + evolving technology and 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. + + 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 & Apel Informational [Page 3] + +RFC 5141 ISO URN Schema March 2008 + + +2. Specification Template + +2.1. Namespace ID + + "iso" + +2.2. Registration Information + + Version 2.1 + Date: 2007-12-13 + +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 (NSSs) of all URNs assigned by ISO + will conform to the syntax defined in Section 2.2 of [RFC2141]. + + The NSS has the following ABNF [RFC5234] 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 *supplement *docelement + [addition] + + The prefix "std:" distinguishes an . An + identifies the ISO document that is designated by the + , as extended or modified by any identified + . (An that identifies all parts of a + multipart ISO document is a special case as described under the + + + +Goodwin & Apel Informational [Page 4] + +RFC 5141 ISO URN Schema March 2008 + + + element .) If the contains an + 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] + + 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" + + 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 Electrotechnique Internationale + + iso-iec = jointly developed by ISO and IEC + + iso-cie = jointly developed by ISO and the Commission + Internationale d'Eclairage (CIE) + + iso-astm = jointly developed by ISO and the American Society for + Testing and Materials (ASTM) International + + 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" + + designates the ISO deliverable type. If the element + is not present, the classification is "international standard". + Other current values: + + data = Data (document type no longer published) + + guide = Guide + + + + +Goodwin & Apel Informational [Page 5] + +RFC 5141 ISO URN Schema March 2008 + + + 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 + + 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 = "-" 1*( DIGIT / ALPHA / "-" ) + + 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 + element. However, this precludes the possibility of using any + further elements except . + + NOTE: The option to refer to a multipart ISO document by omitting + the 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 and , 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 & Apel Informational [Page 6] + +RFC 5141 ISO URN Schema March 2008 + + + NOTE: In the case where the multipart document comprises different + types of ISO deliverable, the 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 is required if + the identified resource is a part of an ISO document. Otherwise, + this element is not used. + + status = ( "draft" / "cancelled" ) / stage + + indicates the publication status of the document. When + the 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] + + indicates the stage code and iteration of the document. + + stagecode = DIGIT DIGIT "." DIGIT DIGIT + + 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 + + is a sequential number that refers to a specific + iteration of the project's lifecycle through the designated stage. + + If no is specified, the reference is to the highest + iteration available for the specified stagecode. + + NOTE: In the ISO Central Secretariat project management database, + the is referred to as the "project version". + + edition = "ed-" DIGITS + + designates a specific edition of the document. (DIGITS + is the (sequential) edition number.) If no is + specified, the NSS refers to the latest edition. + + + + +Goodwin & Apel Informational [Page 7] + +RFC 5141 ISO URN Schema March 2008 + + + docversion = "v" (simpleversion / isoversion) + + simpleversion = DIGITS + + designates the version number of a document's + . 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 , the first version published is 1, and each + subsequent correction or amendment increases the version number by + 1. + + If no is specified, the reference is to the highest + version number available for the denoted . + + Current values of : + + 1 - first version published + + 2 - corrected version published + + isoversion = baseversion *includedsuppl + + baseversion = DIGITS + + includedsuppl = "-" suppltype supplnumber [ "." supplversion ] + + An can be linked to a simpleversion by defining an + existing simpleversion as baseversion and listing all the + elements (corrections and amendments) incorporated + into that version. + + Examples for the (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 & Apel Informational [Page 8] + +RFC 5141 ISO URN Schema March 2008 + + + 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" + + 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 + that 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, is assumed. + + NOTE: Although [ISO639-1] recommends that language codes be + written in lowercase, this ABNF definition allows the use of + uppercase language codes because in ABNF [RFC5234], terminal + symbols defined as literal strings are explicitly + case-insensitive. This case distinction does not carry any + meaning (see Section 2.9) and it is recommended to use language + codes in lowercase. For additional information about the usage of + language tags in information objects, see [RFC4646]. + + supplement = ":" suppltype ":" supplnumber + [":" supplversion ] [":" language ] + + suppltype = "amd" / "cor" / "add" + + supplnumber = DIGITS + + supplversion = "v" DIGITS + + designates a technical alteration of or addition to + an ISO standard that does not result in a new or + . Each may be one of the three types, + designated by : + + + + + + +Goodwin & Apel Informational [Page 9] + +RFC 5141 ISO URN Schema March 2008 + + + amd = Amendment -- a document that alters and/or adds to + previously agreed upon 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 + [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. + + identifies the number of the supplement. + + designates the version of a published supplement. + At present, only two versions are used in practice: when a + supplement is published, it is 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 element + defined above. The interpretation is the same, except that it + applies only to the supplement. + + docelement = ":" ( "clause" / "figure" / "table" / "term" ) ":" + elementnumber / elementrange + *( "," elementnumber / elementrange ) + + elementnumber = ( ALPHA / DIGITS ) *( "." DIGITS ) + + elementrange = elementnumber "-" elementnumber + + + + + +Goodwin & Apel Informational [Page 10] + +RFC 5141 ISO URN Schema March 2008 + + + 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 clauses, figures, tables, and terms only. + It does not provide for reference to subfigures. Revisions of + this specification may define additional values. + + represents the selection of one or more clauses or + subclauses of the document.
represents the selection of + one or more figures of the document. represents the + selection of one or more tables of the document. represents + the selection of one or more terms of the document. + + designates a numbered subdivision in a document, + where the type of subdivision is identified by the literal + "clause", "figure", "table", or "term". When the first character + of is a digit, the reference is to the subdivision + designated by that digit string and by any additional digit + strings separated by periods. When the first character of + is alphabetical, the reference is to the + corresponding Annex, and to the subdivisions designated by + additional digit strings. + + The form HYPHEN designates a range + of subdivisions, and the form COMMA + designates a list. A list can contain ranges. + + addition = techdefined / isodefined + + techdefined = ":tech" *techelement + + techelement = + + isodefined = + + is an additional element 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. + + represents an associated or embedded resource + defined by the committee that develops or maintains the identified + document. All such elements begin with the prefix + ":tech". + + + + + + + +Goodwin & Apel Informational [Page 11] + +RFC 5141 ISO URN Schema March 2008 + + + represents associated or embedded resources defined + by the ISO Central Secretariat. The definition of an + element beginning with any symbol other than is reserved to + the ISO Central Secretariat. + + The syntax of the element is not specified in this RFC. + Specific syntax for this element 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. It is necessary that these definitions + comply with the rules for lexical equivalence specified in Section + 2.9 and take into account the process for identifier resolution as + discussed in Section 2.8. + + DIGITS = DIGIT *DIGIT + + DIGIT = %x30-39 ; 0-9 + + ALPHA = %x41-5A / %x61-7A ; A-Z / a-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 & Apel Informational [Page 12] + +RFC 5141 ISO URN Schema March 2008 + + + 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 + "international standard" is used in the URN. + + + + + + +Goodwin & Apel Informational [Page 13] + +RFC 5141 ISO URN Schema March 2008 + + + o Docversion handling: + + urn:iso:std:iso:9999:-1:ed-1:v2:en + refers to the corrected English version of the 1st edition of ISO + 9999-1 + + urn:iso:std:iso:9999:-1:ed-1:v1-amd1:en + refers to the version comprising the 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 the 2nd edition of ISO 9999-1, in English + + urn:iso:std:iso:9999:-1:ed-2:en:amd:1:v2 + refers to the corrected version of Amendment 1 to the 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 the 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 the 2nd edition of ISO + 9999-1, in English + + + + + + + + +Goodwin & Apel Informational [Page 14] + +RFC 5141 ISO URN Schema March 2008 + + + o Docelement handling: + + urn:iso:std:iso:105:-c12:ed-1:en:clause:a.1,a.2 + urn:iso:std:iso:105:-c12:ed-1:en:clause:a.1-a.2 + both refer to clauses A.1 and A.2 in the 1st edition of ISO + 105-C12, in English + + urn:iso:std:iso:9999:-1:ed-1:v1- + amd1.v1:en,fr:amd:2:v2:en:clause:3.1,a.2-b.9 (isoversion scheme) + refers to (sub)clauses 3.1 and A.2 to B.9 in 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:9999:-1:ed-2:en:amd:1:term:3.2,3.3,3.4.1- + 3.4.4,3.12 + refers to the terms 3.2, 3.3, 3.4.1 to 3.4.4, and 3.12 in + Amendment 1 to the 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]. + +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 the element + . The responsibility of the Technical Committee will + therefore be to ensure the uniqueness of the techdefined + element 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. + + + + +Goodwin & Apel Informational [Page 15] + +RFC 5141 ISO URN Schema March 2008 + + +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", replacing + all occurrences of ":" within the identifier with "/", and + converting characters to lowercase. (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 resources: + + 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 to the . 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 they are octet-by-octet equal after + the following preprocessing: + + 1. normalize the case of the leading "urn:" token + + 2. normalize the case of the NID + + 3. normalize the case of any %-escaping + + 4. normalize the case of all elements + + Further information is specified in [RFC2141], Section 5. + + + + + +Goodwin & Apel Informational [Page 16] + +RFC 5141 ISO URN Schema March 2008 + + +2.10. Conformance with URN Syntax + + No special considerations. + +2.11. Validation Mechanism + + None specified. + +2.12. Scope + + Global. + +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 the author has the ISO reference (or document + identifier). Conversely, it is important that a reader unfamiliar + + + +Goodwin & Apel Informational [Page 17] + +RFC 5141 ISO URN Schema March 2008 + + + 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.) + + 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 part of the 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 bibliographic, 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. + +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 + + + + + +Goodwin & Apel Informational [Page 18] + +RFC 5141 ISO URN Schema March 2008 + + + 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 [RFC2141] + represent the most useful form of formal, globally unambiguous + identifiers. 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. + + 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 + + + +Goodwin & Apel Informational [Page 19] + +RFC 5141 ISO URN Schema March 2008 + + + 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 behavior 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. + +5. IANA Considerations + + IANA has assigned "iso" (29) as 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. + +6. Security Considerations + + The ISO URN Namespace ID shares the security considerations outlined + in [RFC3406], but has no other known security considerations. + + + +Goodwin & Apel Informational [Page 20] + +RFC 5141 ISO URN Schema March 2008 + + +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. + + [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. + Faltstrom, "Uniform Resource Names (URN) Namespace + Definition Mechanisms", BCP 66, RFC 3406, October 2002. + + [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, January + 2008. + +7.2. Informative References + + [ISO8879:1986] + International Organization for Standardization, + "Information processing -- Text and office systems -- + Standard Generalized Markup Language (SGML)", ISO + 8879:1986. + + [ISO/IEC9070:1991] + International Organization for Standardization, + "Information technology -- SGML support facilities -- + Registration procedures for public text owner + identifiers", ISO/IEC 9070:1991. + + + + +Goodwin & Apel Informational [Page 21] + +RFC 5141 ISO URN Schema March 2008 + + + [ISO/IEC8824-1:2002] + International Organization for Standardization, + "Information technology -- Abstract Syntax Notation One + (ASN.1): Specification of basic notation -- Part 1", + ISO/IEC 8824-1:2002. + + [ISO/IEC8825:1987] + International Organization for Standardization, + "Information processing systems -- Open Systems + Interconnection -- Specification of Basic Encoding Rules + for Abstract Syntax Notation ONE (ASN.1)", ISO/IEC + 8825:1987. + + [CCITT] "Specification of Basic Encoding Rules for Abstract + Syntax Notation One (ASN.1)", CCITT Recommendation + X.209, January 1988. + + [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. + + [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying + Languages", BCP 47, RFC 4646, September 2006. + + + + + + + + + + + + + + + + + + + + + + + + + + +Goodwin & Apel Informational [Page 22] + +RFC 5141 ISO URN Schema March 2008 + + +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/IEC8824-1:2002] (original + edition 1984; [RFC3061] cites the 1988 [CCITT] edition of the + encoding rules in [ISO/IEC8825:1987]. This standard assigned the + registry authority for all identifiers in the { iso(1) } namespace to + ISO, 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 Standard Generalized Markup + Language (SGML) [ISO8879:1986] and [ISO/IEC9070: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 & Apel Informational [Page 23] + +RFC 5141 ISO URN Schema March 2008 + + + 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. 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, the 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. + +Appendix B. ABNF Definition of Namespace ID = "iso" (Informative) + + NSS = std-nss + + std-nss = "std:" docidentifier *supplement *docelement + [addition] + + docidentifier = originator [":" type] ":" docnumber [":" partnumber] + [[":" status] ":" edition] + [":" docversion] [":" language] + + originator = "iso" / "iso-iec" / "iso-cie" / "iso-astm" / + "iso-ieee" / "iec" + + ; iso = International Organization for + ; Standardization + + ; iec = International Electrotechnical + ; Commission (IEC), or Commission + ; Electrotechnique Internationale + + ; iso-iec = jointly developed by ISO and IEC + + + + + +Goodwin & Apel Informational [Page 24] + +RFC 5141 ISO URN Schema March 2008 + + + ; iso-cie = jointly developed by ISO and the + ; Commission Internationale d'Eclairage + ; (CIE) + + ; iso-astm = jointly developed by ISO and the + ; American Society for Testing and + ; Materials (ASTM) International + + ; iso-ieee = jointly developed by ISO and the + ; Institute for Electrical and + ; Electronics Engineers (IEEE) + + type = "data" / "guide" / "isp" / "iwa" / + "pas" / "r" / "tr" / "ts" / "tta" + + ; data = Data (document type no longer published) + + ; 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 + + partnumber = "-" 1*( DIGIT / ALPHA / "-" ) + + status = ( "draft" / "cancelled" ) / stage + + ; 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] + + + +Goodwin & Apel Informational [Page 25] + +RFC 5141 ISO URN Schema March 2008 + + + stagecode = DIGIT DIGIT "." DIGIT DIGIT + + iteration = "v" DIGITS + + edition = "ed-" DIGITS + + docversion = "v" (simpleversion / isoversion) + + simpleversion = DIGITS + + ; 1 = first version published + + ; 2 = corrected version published + + isoversion = baseversion *includedsuppl + + baseversion = DIGITS + + includedsuppl = "-" suppltype supplnumber [ "." supplversion ] + + language = monolingual / bilingual / trilingual + + monolingual = "en" / "fr" / "ru" / "es" / "ar" + + bilingual = "en,fr" / "en,ru" / "fr,ru" + + trilingual = "en,fr,ru" + + supplement = ":" suppltype ":" supplnumber + [":" supplversion ] [":" language ] + + suppltype = "amd" / "cor" / "add" + + ; amd = Amendment + + ; cor = Technical Corrigendum + + ; add = Addendum + + supplnumber = DIGITS + + supplversion = "v" DIGITS + + docelement = ":" ( "clause" / "figure" / "table" / "term" ) ":" + elementnumber / elementrange + *( "," elementnumber / elementrange ) + + elementnumber = ( ALPHA / DIGITS ) *( "." DIGITS ) + + + +Goodwin & Apel Informational [Page 26] + +RFC 5141 ISO URN Schema March 2008 + + + elementrange = elementnumber "-" elementnumber + + addition = techdefined / isodefined + + techdefined = ":tech" *techelement + + techelement = + + isodefined = + + DIGITS = DIGIT *DIGIT + + DIGIT = %x30-39 ; 0-9 + + ALPHA = %x41-5A / %x61-7A ; A-Z / a-z + +Authors' Addresses + + Joanna Goodwin + International Organization for Standardization + Case Postal 56 + Geneva 20 1211 + Switzerland + + EMail: goodwin@iso.org + URI: http://www.iso.org + + + Holger Apel + International Organization for Standardization + Case Postal 56 + Geneva 20 1211 + Switzerland + + EMail: apel@iso.org + URI: http://www.iso.org + + + + + + + + + + + + + + + +Goodwin & Apel Informational [Page 27] + +RFC 5141 ISO URN Schema March 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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. + + + + + + + + + + + + +Goodwin & Apel Informational [Page 28] + -- cgit v1.2.3