RFC 5141
A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO)
A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO) 🌸
okay so this is RFC 5141 💖 It's from the Network Working Group, written by J. Goodwin and H. Apel (both from ISO), and it's marked Informational, so it's sharing info, not setting a standard 🎀. The date is March 2008. The header doesn't list any obsoletes or updates, so it isn't replacing or changing anything else 🦋
Status of This Memo 📜
bestie, this part is the disclaimer ✨ It gives info to the Internet community and does not specify an Internet standard of any kind. Distribution is unlimited, so share it with everyone 🫶
Abstract ✨
so this doc describes a URN NID (Uniform Resource Name Namespace Identification) for ISO, the International Organization for Standardization 🔥 It's meant for identifying persistent resources that the ISO standards body publishes. That covers documents, document metadata, extracted stuff like standard schemata and standard value sets, and other resources too 💅
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) .........................................241. Introduction ✨
so ISO was created by international agreement in 1947 🧚 It's a network of the national standards institutes of many countries, with one member per country, and a Central Secretariat in Geneva, Switzerland, that keeps the whole system running 🌈 ISO works as a bridge where everyone can agree on solutions that meet both business requirements and the wider needs of society, like those of stakeholder groups such as consumers and users 💜
more info is at http://www.iso.org/iso/about.htm 🍓
the core mission is making technical standards that give the framework for compatible technology worldwide 👑 ISO standards help make development, manufacturing, and supply of products and services more efficient, safer, and cleaner ✨ They also make trade between countries easier and fairer 💖
every participating full member has the right to take part in developing any standard it thinks is important to its country's economy 🔥 No matter how big or strong an economy is, each participating member gets one vote 🗳️ So it's a democratic setup where every country is on equal footing to influence the strategic direction of ISO's work and the technical content of individual standards 🫶 The standards are voluntary, but they're developed in response to market demand and based on consensus among interested parties, which is why they're widely applicable 🦋 Consensus changes along with technology, so ISO reviews 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 across many nations 💅 These 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 resources useful for international trade and industry 🎀 ISO wants to create and manage globally unique, persistent, location-independent identifiers for these resources 🌟
this spec defines the syntax for URNs that identify documents developed by ISO under the standards development procedures in the ISO/IEC Directives, Part 1 [ISODIR-1] and the ISO supplement [ISODIR-S], and processed by the ISO Central Secretariat 💖 The syntax also extends to document metadata and resources related to those documents or otherwise associated with them 🧚 It does not cover products derived from these documents and published by ISO (like handbooks or compendia), or documents at or below the Technical Committee level 🙈 Future revisions may define syntax for URNs in this namespace that identify other ISO objects, once the ISO community defines a requirement for such identifiers 🔮
2. Specification Template 💅
2.1. Namespace ID
the Namespace ID is "iso" 🎀
2.2. Registration Information
Version 2.1
Date: 2007-12-132.3. Declared Registrant of the Namespace
the declared registrant is J. Goodwin at the ISO Central Secretariat 🌈
J. Goodwin
ISO Central Secretariat
International Organization for Standardization (ISO)
Case Postale 56
CH-1211 Geneva 20
Switzerland
E-mail: goodwin@iso.org2.4. Declaration of Structure
2.4.1. Definition
okay this is where the structure gets real 🤓 The Namespace Specific Strings (NSSs) of all URNs assigned by ISO will conform to the syntax in Section 2.2 of [RFC2141] ✨
the NSS follows this ABNF [RFC5234] spec 💜
NSS = std-nssall URNs under this spec start the NSS with the prefix "std:" 🦋 That's how it's restricted to documents developed through the ISO standards development procedures in the ISO/IEC Directives, Part 1 [ISODIR-1] and the ISO Supplement [ISODIR-S] 🫶 Prefixes for ISO objects of other kinds may be defined in future revisions of this spec 🔮
std-nss = "std:" docidentifier *supplement *docelement
[addition]the "std:" prefix tells you it's an <std-nss> 💖 An <std-nss> identifies the ISO document designated by the <docidentifier>, as extended or modified by any identified <supplement> 🌸 (An <std-nss> that identifies all parts of a multipart ISO document is a special case, described under the element <partnumber>.) If the <std-nss> has an <addition> element, the NSS identifies a resource extracted from the ISO document or otherwise associated with it, as explained below 🧚
docidentifier = originator [":" type] ":" docnumber [":" partnumber]
[[":" status] ":" edition]
[":" docversion] [":" language]<docidentifier> gives 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) that a document comes from 🌈
current values for <originator> are:
iso= International Organization for Standardizationiec= International Electrotechnical Commission (IEC), or Commission Electrotechnique Internationaleiso-iec= jointly developed by ISO and IECiso-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) Internationaliso-ieee= jointly developed by ISO and the Institute for Electrical and Electronics Engineers (IEEE)
revisions of this spec may define additional values 🔥
type = "data" / "guide" / "isp" / "iwa" /
"pas" / "r" / "tr" / "ts" / "tta"<type> designates the ISO deliverable type 💖 If the <type> element isn't there, the classification is "international standard" ✨ Other current values are:
data= Data (document type no longer published)guide= Guideisp= International Standardized Profileiwa= International Workshop Agreementpas= Publicly Available Specificationr= Recommendation (document type no longer published)tr= Technical Reportts= Technical Specificationtta= Technology Trends Assessment
docnumber = DIGITS<docnumber> is the reference number ISO and/or IEC assigns to the document 🦋 An ISO document may be a single document, or two or more separate parts, each identified by <partnumber> 🫶
partnumber = "-" 1*( DIGIT / ALPHA / "-" )<partnumber> is the reference number that identifies a part of a multipart standard 🌸
if you need to refer to a multipart ISO document in its entirety, you can leave out the <partnumber> element 🧚 But that rules out using any further elements except <addition> 🙈
NOTE: leaving out the<partnumber>element to refer to a multipart ISO document was added to match the provision in the ISO/IEC Directives, Part 2, 2004 [ISODIR-2] subclause 6.2.2, which makes an undated reference to all parts of an ISO document. It is only allowed when the URN refers to a multipart ISO document in its entirety. Since this option rules out<status>and<edition>, it's implicit that the URN needs to remain valid no matter what future changes happen to the multipart document (see the rules for undated references 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. 💀
NOTE: when a multipart document is made of 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". 👑
Okay bestie, <partnumber> is required if the thing you're pointing at is a part of an ISO document 📚, unless you're referring to a multipart document in its entirety. Otherwise it's not used at all 💅
status = ( "draft" / "cancelled" ) / stage<status> tells you the publication status of the document ✨ If the <status> element isn't there, the NSS is talking about a published document. The other values are:
draft= a document that hasn't been accepted for publication by international ballot yet 🌸cancelled= a document that has been deleted or withdrawn 💀
stage = "stage-" stagecode ["." iteration]<stage> gives you the stage code and iteration of the document 🦋
stagecode = DIGIT DIGIT "." DIGIT DIGIT<stagecode> is the harmonized stage code, following ISO Guide 69:1999, "Harmonized Stage Code system (Edition 2) -- Principles and guidelines for use" [ISOGUIDE69]. Iconic. 👑
iteration = "v" DIGITS<iteration> is a sequential number that points to a specific pass through the project's lifecycle while it's sitting in its designated stage 🔁
If you don't specify an <iteration>, you get the highest iteration available for the stagecode you picked 💖
NOTE: In the ISO Central Secretariat project management database, the <iteration> is called the "project version" 🎀
edition = "ed-" DIGITS<edition> designates one specific edition of the document. The DIGITS part is the sequential edition number 🌈 If you leave out <edition>, the NSS goes for the latest edition ✨
docversion = "v" (simpleversion / isoversion)
simpleversion = DIGITS<docversion> is the version number of a document's <edition> 🧚 It changes through a correction (a corrected version, aka a Technical Corrigendum) or an amendment (an Amendment or Addendum). It is not the same as a revision, which changes the edition number. Different thing, bestie! 🙈
In the <simpleversion>, the first version published is 1, and each correction or amendment after that bumps the number up by 1 💜
If you don't specify a <docversion>, you get the highest version number available for the edition you named 🍓
Current values of <simpleversion>:
1 - first version published
2 - corrected version publishedisoversion = baseversion *includedsuppl
baseversion = DIGITS
includedsuppl = "-" suppltype supplnumber [ "." supplversion ]An <isoversion> can be linked to a simpleversion. You do this by making an existing simpleversion the baseversion and listing every <supplement> (corrections and amendments) that got folded 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
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 3language = monolingual / bilingual / trilingual
monolingual = "en" / "fr" / "ru" / "es" / "ar"
bilingual = "en,fr" / "en,ru" / "fr,ru"
trilingual = "en,fr,ru"<language> names the official ISO language(s), or the language of an official translation, that the document is processed and published in by ISO 🌍 It skips languages that only show up in specific bits of the content. The value is one or more alpha-2 codes, each one a language as defined in ISO 639-1 [ISO639-1]. If you don't include a language element, <en> is assumed 🇬🇧
NOTE: Even though [ISO639-1] says language codes should be written in lowercase, this ABNF lets you use uppercase too. That's because in ABNF [RFC5234], terminal strings written as literals are case-insensitive. The case doesn't mean anything (see Section 2.9), but it is recommended to use lowercase language codes anyway. For more on language tags in information objects, check out [RFC4646] 🔤
supplement = ":" suppltype ":" supplnumber
[":" supplversion ] [":" language ]
suppltype = "amd" / "cor" / "add"
supplnumber = DIGITS
supplversion = "v" DIGITS<supplement> is a technical tweak to, or addition on, an ISO standard that doesn't create a new <edition> or <version> 🛠️ Every <supplement> is one of three types, picked by <suppltype>:
amd= Amendment, a document that changes and/or adds to technical provisions already agreed upon in an existing ISO document. An amendment needs to be accepted by ballot under the ISO/IEC Directives, Part 1, 2004 [ISODIR-1] subclause 2.10.3 🗳️cor= Technical Corrigendum, a document that fixes a technical error or ambiguity, or updates the ISO document in a way that doesn't touch 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, which is a document type no longer published 🕰️ Addenda used to be documents that changed the technical requirements of an ISO document (by correction, addition, or deletion), and they had to be accepted by ballot under the ISO/IEC Directives, Part 1. (Addenda are still included in this RFC because some of them are still valid 💖)
Supplements get numbered one after another per ISO document, and within each supplement type 🔢
<supplnumber> tells you the number of the supplement 🎯
<supplversion> is the version of a published supplement. Right now only two versions really get used. When a supplement is first published, it's version 1. If it later gets corrected by issuing a corrected version (marked "Corrected" on the cover page along with a date), that corrected version is version 2 🩷
The language of a supplement can be different from the language of the document. For example, a supplement might only apply to one of the languages in a bilingual document. In those cases you can use the <language> element defined above to say which language the supplement is in. The meaning stays the same, except it only applies to the supplement 🌸
docelement = ":" ( "clause" / "figure" / "table" / "term" ) ":"
elementnumber / elementrange
*( "," elementnumber / elementrange )
elementnumber = ( ALPHA / DIGITS ) *( "." DIGITS )
elementrange = elementnumber "-" elementnumber<docelement> points at one or more numbered subdivisions of a document 📖 The types of numbered subdivision are specified in the ISO/IEC Directives, Part 2 [ISODIR-2]. This RFC only sets up forms for referring to clauses, figures, tables, and terms. It doesn't cover subfigures. Future revisions of this spec might add more values 🔮
<clause> selects one or more clauses or subclauses of the document. <figure> selects one or more figures. <table> selects one or more tables. <term> selects one or more terms 🧾
<elementnumber> designates a numbered subdivision in a document, where the type of subdivision is the literal "clause", "figure", "table", or "term". When the first character of <elementnumber> is a digit, the reference goes to the subdivision named by that digit string, plus any extra digit strings separated by periods. When the first character of <elementnumber> is a letter, the reference goes to the matching Annex, plus any subdivisions named by extra digit strings 🏛️
The form <elementnumber> HYPHEN <elementnumber> designates a range of subdivisions, and the form <elementnumber> COMMA <elementnumber> designates a list. A list can contain ranges too 🎀
addition = techdefined / isodefined
techdefined = ":tech" *techelement
techelement = <unspecified>
isodefined = <unspecified><addition> is an extra element of the NSS that identifies a representation of an ISO document, an extract from one, or some related information set, as a resource in its own right 🎁
<techdefined> is an associated or embedded resource defined by the committee that develops or maintains the identified document. All of these <addition> elements start with the prefix ":tech" 🛎️
<isodefined> is associated or embedded resources defined by the ISO Central Secretariat. Any <addition> element that begins with a symbol other than <tech> is reserved for the ISO Central Secretariat 🔒
The syntax of the <addition> element isn't specified in this RFC. Specific syntax will be specified as needed by the ISO Central Secretariat, or by the individual committee responsible for developing or maintaining the identified document. These definitions have to comply with the lexical equivalence rules in Section 2.9, and they have to take into account the identifier resolution process discussed in Section 2.8 🧠
DIGITS = DIGIT *DIGIT
DIGIT = %x30-39 ; 0-9
ALPHA = %x41-5A / %x61-7A ; A-Z / a-zBasics 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
<a>*<b> indicates that the following term or group can repeat at
least <a> and at most <b> times; default values are 0 and
infinity, respectively
; comment2.4.2. Examples ✨
okay bestie, the examples are where this schema really shows off 💅 Every one of these is a real URN, so I'm keeping them character for character in code blocks.
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)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 EnglishStatus: 🦋 the status part is giving main character energy
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 30Non-numeric part number: 🧚
urn:iso:std:iso:9999:-A02:ed-1:en
refers to the 1st edition of ISO 9999-A02, in EnglishReference to a resource related to all parts of a multipart document: 🌈 this one is so cute
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 this schema was drafted, ISO 20022 had 5 parts: parts 1 and 2 are International Standards, and parts 3 to 5 are Technical Specifications. That's why the <doctype> "international standard" is used in the URN. 🙈
Docversion handling: 💜 the versions are so layered
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
EnglishSupplement 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 EnglishDocelement handling: ⭐ the clause and term picks are so precise
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 English2.5. Relevant Ancillary Documentation 📚
the extra reading here is ISO/IEC Directives, Part 1 [ISODIR-1] and Part 2 [ISODIR-2], plus the ISO supplement [ISODIR-S]. 🫶
2.6. Identifier Uniqueness Considerations 🔐
okay so the ISO Central Secretariat manages URN assignment for documents in the requested namespace, and it makes sure those URNs line up with the ISO Directives for uniquely identifying ISO documents. ✨
the Technical Committees handle URNs for their resources related to ISO documents. each of those URNs extends the containing document's URN through the <addition> element. so the TC's job is making sure the techdefined <addition> element is unique within the document namespace, which keeps the whole resource identifier unique in the requested namespace. 💅
2.7. Identifier Persistence Considerations 🌸
assigned URNs are never reused and stay valid even after the referenced resource's lifecycle is over. ngl that's iconic. 💖 Just note that, even though the URN stays valid, the status of the referenced resource can still change. 🙈
2.8. Process for Identifier Resolution 🗺️
Resolving document identifiers:
this schema is built so a URN for an ISO document can become a valid http URI. you swap the "iso" namespace prefix and the "std:" prefix for the domain standards.iso.org, replace every ":" in the identifier with "/", and lowercase all the characters. (ISO is planning a website 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:
for URNs in the requested namespace that point to extra resources related to ISO documents, the ISO Central Secretariat will specify the resolution procedure when it defines the syntax for the matching <addition> in the <std-nss>. most of the time those resources will live on an ISO website, as extensions of the http URIs above. 🌈
2.9. Rules for Lexical Equivalence 🪞
two URNs are lexically equivalent if they're octet-by-octet equal after these steps:
- normalize the case of the leading "urn:" token
- normalize the case of the NID
- normalize the case of any %-escaping
- normalize the case of all elements
more info is in [RFC2141], Section 5. 📖
2.10. Conformance with URN Syntax 🎀
no special considerations here, bestie. ✨
2.11. Validation Mechanism 🫧
none specified. 🤷♀️
2.12. Scope 🌍
global. 🌏
3. Namespace Considerations 💜
the ISO-specific requirements are giving a whole wishlist:
- globally unique, persistent identifiers
- location-independent identifiers
- human-interpretable identifiers
- a scheme applicable to paper documents as well as machine-readable documents
- a scheme applicable to conceptual documents and explicit forms of documents
- a scheme applicable to resources extracted from documents
- a scheme applicable to "metadata" associated with documents
- a scheme in which the identifier assignment is managed by the ISO Central Secretariat
Location-independence: ISO standards come out through a complicated mix of development organizations and national standards institutes, so one ISO document can be available in lots of forms from lots of sources. That's why the identifier needs to be global, widely and uniformly used, and independent of whichever text source a given reference uses. 🌐
Human-interpretable: lots of document references get written by humans, so an author who knows the scheme should be able to build a correct URN from the ISO reference (or document identifier). a reader who doesn't know the scheme should also be able to tell that the URN points to an ISO document, especially an ISO standard, and recognize the identifiers for forms, languages, or metadata sets. 🧠✨
Paper documents: older ISO standards that industry still uses as references may exist only on paper or in earlier machine-readable formats that aren't common on the Internet. the identifier scheme needs to cover these too. (many have been converted to Internet forms, and more are on the way, but the identifier should stay independent of whatever form the document is available in at any given time.) 📜
Conceptual documents vs. representation forms: ISO documents get maintained and re-published in multiple forms, so the identifiers need to point to the conceptual document, regardless of publication form. some uses still need specific editions or publication forms, like editions in different languages or PDF and HTML versions. this URN spec handles those cases in the <isodefined> part of the <addition> element. 🦋
Document extracts: ISO standards can contain formal specifications in machine-processable languages, or formal specifications that also have machine-processable representations. being able to pull those out as separate resources is useful, so those "extracted resources" get global identifiers derived from the document identifier with a consistent scheme. 🧩
Document metadata: some uses of documents, mostly bibliographic ones, pull information out of the documents. that information, usually called "metadata", is organized in machine-readable forms defined by other standards, and those metadata sets become resources in their own right. they need URN identifiers that match the document identification scheme. 💖
4. Community Considerations ✨
Okay so the ISO community is broad in two dimensions 💅 In one dimension, its documents get developed and used in a huge variety of industries and professions: natural sciences, manufacturing, construction, transportation, information technology, social sciences, etc. In the other dimension, it's a community of expert developers, standards managers, publishers, professional users, and consumers. And Internet information technologies are part of common professional practice in all of these areas, in both dimensions 🌈
ISO standards get cited in business agreements, professional publications, product descriptions, and standards development and publication activities. When these citations show up in electronic form, the references must be unambiguous 🎀
The information technology community is itself very active in developing and using standards, and lots of 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 make existing and emerging Internet technologies work for all of these purposes, URNs conforming to [RFC2141] are the most useful form of formal, globally unambiguous identifiers 🦋 A managed namespace for such identifiers, following a consistent scheme for identifying ISO documents and their derivatives, would be a huge benefit to the entire ISO community. Iconic, honestly 👑
- 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 ISO Central Secretariat manages the assignment of identifiers under this scheme, the processes by which the identified objects arise and acquire those 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 adopting practices too early. Those practices aren't completely specified yet, or haven't reached consensus, and therefore may well change 🙈
It should also be noted that ISO documents are not, in general, freely available over the Internet. Instead, there are complex agreements between ISO and its member institutes about the rights to the publications, and about the 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. It may instead lead to a site that can provide that text for a fee, or 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. Slay, it's official 🔥
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. So go read [RFC3406] 🔒💀
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.
[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.Appendix A. Alternative Naming Schemes ✨
okay so before ISO even asked for a new namespace, they went shopping for an existing one first 🛍️ and two schemes got a serious look because they each kinda covered part of what they needed:
The OID scheme comes from the joint ISO/ITU-T ASN.1 object-identifier scheme in [ISO/IEC8824-1:2002] (original edition 1984; [RFC3061] cites the 1988 [CCITT] edition of the encoding rules in [ISO/IEC8825:1987]). This standard gave the registry authority for everything in the { iso(1) } namespace to ISO, so ISO is the one in charge of every identifier starting with oid:1: 👑 And honestly? ISO has already built and uses an ASN.1 identification scheme that hits most of the requirements. It could define an OID use that does everything it needs, but that would make the already-complicated ASN.1 situation even more complicated 😭
The original idea behind ISO 8824 was to allow a human-readable form, for easy recognition, and an encoding that used as few bits as possible when sent over a network. Regrettably 💀, the encoding picked in RFC 3061 is way closer to the minimal-bits version than the human-readable one. The NSS for the OID scheme is all 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
Not gonna lie, that's really hard for a human to read or write 🙈 It's also easy to mistype, and there are no "check-digits" in the scheme, which makes it hard to validate. That leads to URNs floating around that are invalid, or valid but wrong 😬 And since the all-numeric form doesn't hint at the name of the responsible organization, there's no hint of any URL that could help a human figure out the reference. So the OID scheme makes all the required identifiers technically possible and technically usable by software, but for all practical purposes, OID URNs are only useful to software 🤖
The PublicId scheme comes from Standard Generalized Markup Language (SGML) [ISO8879:1986] and the [ISO/IEC9070:1991] bibliographic catalogue forms. Narrowed down to ISO publications, it's good enough for the unique, global, persistent identification of published documents, in both paper and machine-processable form 📚🌸
Here's the thing though: the PublicId scheme does not have a "conceptual document" notion. It identifies specific publications and editions 🙅♀️ "Weak identification" could be used to build the conceptual document idea, but the PublicId scheme doesn't document that interpretation. Also, it doesn't extend to draft documents (which get referenced a lot in pilot implementations), to separate forms of a document, or to resources pulled out of documents. It only supports the metadata elements defined in SGML. The scheme could be extended to cover most of these, but ISO-specific extensions wouldn't really extend to the much bigger base of documents identified by PublicIds. (Version and edition management practices vary a lot across publishers, depending on their milieu.) And finally, the ISO Central Secretariat could not and should not control the registry of such URNs 🙃
So ISO concluded the alternative schemes just aren't adequate for what the ISO community needs 🫶
Even though ISO asked for a new namespace for its documents and their derivatives, it doesn't want to discourage people from using these other identifiers for ISO publications. The PublicId form especially is useful for referring to ISO publications in a larger bibliographic information space 💜
Appendix B. ABNF Definition of Namespace ID = "iso" (Informative) 🎀
Okay, bestie, here's the grammar. It's informative, so it's the reference version for looking things up, not something you have to run on 🧚
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
; 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]
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 )
elementrange = elementnumber "-" elementnumber
addition = techdefined / isodefined
techdefined = ":tech" *techelement
techelement = <unspecified>
isodefined = <unspecified>
DIGITS = DIGIT *DIGIT
DIGIT = %x30-39 ; 0-9
ALPHA = %x41-5A / %x61-7A ; A-Z / a-zAuthors' 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
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.
📦 where this page comes from
- ietf: rfc5141 2008-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms