    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 <std-nss>.  An <std-nss>
          identifies the ISO document that is 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 as described under the

    Goodwin & Apel               Informational                      [Page 4]

    RFC 5141                     ISO URN Schema                   March 2008

          element <partnumber>.)  If the <std-nss> contains an <addition>
          element, the NSS identifies a resource extracted from the ISO
          document or otherwise associated with it (see below).

       docidentifier = originator [":" type] ":" docnumber [":" partnumber]
                       [[":" status] ":" edition]
                       [":" docversion] [":" language]

          <docidentifier> provides the complete identification of an ISO
          document.  Each of its component elements is described below.

       originator    = "iso" / "iso-iec" / "iso-cie" / "iso-astm" /
                       "iso-ieee" / "iec"

          <originator> is the organization (usually an international body)
          from which a document emanates.

          Current values:

          iso      = International Organization for Standardization

          iec      = International Electrotechnical Commission (IEC), or
                     Commission 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"

          <type> designates the ISO deliverable type.  If the <type> element
          is not present, the classification is "international standard".
          Other current values:

          data  = Data (document type no longer published)

          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

          <docnumber> is the reference number assigned to the document by
          ISO and/or IEC.  An ISO document may comprise a single document,
          or two or more separate parts each of which is identified by
          <partnumber>.

       partnumber    = "-" 1*( DIGIT / ALPHA / "-" )

          <partnumber> is the reference number that identifies a part of a
          multipart standard.

          Where it is required to refer to a multipart ISO document in its
          entirety, this can be designated by omitting the <partnumber>
          element.  However, this precludes the possibility of using any
          further elements except <addition>.

          NOTE: The option to refer to a multipart ISO document by omitting
          the <partnumber> element has been included to align with the
          provision in the ISO/IEC Directives, Part 2, 2004 [ISODIR-2]
          subclause 6.2.2 of making an undated reference to all parts of an
          ISO document.  It is only permissible to use this option where the
          URN is referring to a multipart ISO document in its entirety.
          Since the use of this option precludes the designation of the
          elements <status> and <edition>, it is implicit that the URN needs
          to remain valid irrespective of any future changes to the
          multipart document (see the rules for undated references given in
          the ISO/IEC Directives, Part 2, 2004 [ISODIR-2] subclause
          6.6.7.5.2).  This shall be taken into consideration in the use
          (and maintenance) of any URN specification employing this option.

    Goodwin & 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 <type> of the core part (usually
          part 1) applies.  See the example "Reference to a resource related
          to all parts of a multipart document".

          Except for the case where it is required to refer to a multipart
          document in its entirety, the element <partnumber> is required if
          the identified resource is a part of an ISO document.  Otherwise,
          this element is not used.

       status        = ( "draft" / "cancelled" ) / stage

          <status> indicates the publication status of the document.  When
          the <status> element is not present, the NSS refers to a published
          document.  Other values:

          draft     = document that has not yet been accepted for
                      publication by international ballot

          cancelled = document that has been deleted or withdrawn

       stage         = "stage-" stagecode ["." iteration]

          <stage> indicates the stage code and iteration of the document.

       stagecode     = DIGIT DIGIT "."  DIGIT DIGIT

          <stagecode> is the harmonized stage code in accordance with ISO
          Guide 69:1999, "Harmonized Stage Code system (Edition 2) --
          Principles and guidelines for use" [ISOGUIDE69].

       iteration     = "v" DIGITS

          <iteration> is a sequential number that refers to a specific
          iteration of the project's lifecycle through the designated stage.

          If no <iteration> is specified, the reference is to the highest
          iteration available for the specified stagecode.

          NOTE: In the ISO Central Secretariat project management database,
          the <iteration> is referred to as the "project version".

       edition       = "ed-" DIGITS

          <edition> designates a specific edition of the document.  (DIGITS
          is the (sequential) edition number.)  If no <edition> is
          specified, the NSS refers to the latest edition.

    Goodwin & Apel               Informational                      [Page 7]

    RFC 5141                     ISO URN Schema                   March 2008

       docversion    = "v" (simpleversion / isoversion)

       simpleversion = DIGITS

          <docversion> designates the version number of a document's
          <edition>.  It is altered by correction (corrected version;
          Technical Corrigendum) or amendment (Amendment; Addendum) and is
          distinct from a revision, which changes the edition number.

          In the <simpleversion>, the first version published is 1, and each
          subsequent correction or amendment increases the version number by
          1.

          If no <docversion> is specified, the reference is to the highest
          version number available for the denoted <edition>.

          Current values of <simpleversion>:

             1 - first version published

             2 - corrected version published

       isoversion    = baseversion *includedsuppl

       baseversion   = DIGITS

       includedsuppl = "-" suppltype supplnumber [ "." supplversion ]

          An <isoversion> can be linked to a simpleversion by defining an
          existing simpleversion as baseversion and listing all the
          <supplement> elements (corrections and amendments) incorporated
          into that version.

          Examples for the <isoversion> (internal ISO version) scheme:

             1 = first version of standard

             1-amd1.v1 =  first version of standard incorporating first
             version of Amendment 1

             1-amd1.v1-amd2.v1 = first version of standard incorporating
             first version of Amendment 1 and first version of Amendment 2

             1-amd1.v2-amd2.v1-amd3 = first version of standard
             incorporating corrected version of Amendment 1, first version
             of Amendment 2, and highest version of Amendment 3

    Goodwin & 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"

          <language> designates the official ISO language(s), or the
          language of an official translation, in which the document
          (object) is processed and published by ISO (excluding languages
          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, <en> 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

          <supplement> designates a technical alteration of or addition to
          an ISO standard that does not result in a new <edition> or
          <version>.  Each <supplement> may be one of the three types,
          designated by <suppltype>:

    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.

          <supplnumber> identifies the number of the supplement.

          <supplversion> designates the version of a published supplement.
          At present, only two versions are used in practice: when a
          supplement is published, it is version 1.  If that supplement is
          subsequently corrected by issuing a corrected version, as
          designated by the term "Corrected" on the cover page together with
          a date, the corrected version is version 2.

          The language of a supplement can be different from that of the
          document.  For example, a supplement may apply to only one of the
          languages of a bilingual document.  For such cases, the language
          of a supplement can be identified using the <language> element
          defined above.  The interpretation is the same, except that it
          applies only to the supplement.

          docelement    = ":" ( "clause" / "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

          <docelement> identifies one or more numbered subdivisions of a
          document.  Types of numbered subdivision are specified in the ISO/
          IEC Directives, Part 2 [ISODIR-2].  This RFC currently specifies
          forms for reference to clauses, figures, tables, and terms only.
          It does not provide for reference to subfigures.  Revisions of
          this specification may define additional values.

          <clause> represents the selection of one or more clauses or
          subclauses of the document. <figure> represents the selection of
          one or more figures of the document. <table> represents the
          selection of one or more tables of the document. <term> represents
          the selection of one or more terms of the document.

          <elementnumber> 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 <elementnumber> 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
          <elementnumber> is alphabetical, the reference is to the
          corresponding Annex, and to the subdivisions designated by
          additional 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.

       addition      = techdefined / isodefined

       techdefined   = ":tech" *techelement

       techelement   = <unspecified>

       isodefined    = <unspecified>

          <addition> 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.

          <techdefined> represents an associated or embedded resource
          defined by the committee that develops or maintains the identified
          document.  All such <addition> elements begin with the prefix
          ":tech".

    Goodwin & Apel               Informational                     [Page 11]

    RFC 5141                     ISO URN Schema                   March 2008

          <isodefined> represents associated or embedded resources defined
          by the ISO Central Secretariat.  The definition of an <addition>
          element beginning with any symbol other than <tech> is reserved to
          the ISO Central Secretariat.

          The syntax of the <addition> 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

       <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

       ;   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 <doctype>
          "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
       <addition>.  The responsibility of the Technical Committee will
       therefore be to ensure the uniqueness of the techdefined <addition>
       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 <addition> 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 <addition> to the <std-nss>.  In most
          cases, those resources will be maintained on an ISO website, as
          extensions to the http URIs described above.

    2.9.  Rules for Lexical Equivalence

       URNs are lexically equivalent if 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 <isodefined> part of the <addition> 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   = <unspecified>

       isodefined    = <unspecified>

       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]