doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc5141.txt b/doc/rfc/rfc5141.txt
new file mode 100644
index 0000000..1681d68
--- /dev/null
+++ b/doc/rfc/rfc5141.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group                                         J. Goodwin
+Request for Comments: 5141                                       H. Apel
+Category: Informational                                              ISO
+                                                              March 2008
+
+
+              A Uniform Resource Name (URN) Namespace for
+        the International Organization for Standardization (ISO)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Abstract
+
+   This document describes a Uniform Resource Name Namespace
+   Identification (URN NID) for the International Organization for
+   Standardization (ISO).  This URN NID is intended for use for the
+   identification of persistent resources published by the ISO standards
+   body (including documents, document metadata, extracted resources
+   such as standard schemata and standard value sets, and other
+   resources).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goodwin & Apel               Informational                      [Page 1]
+
+RFC 5141                     ISO URN Schema                   March 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Specification Template ..........................................4
+      2.1. Namespace ID ...............................................4
+      2.2. Registration Information ...................................4
+      2.3. Declared Registrant of the Namespace .......................4
+      2.4. Declaration of Structure ...................................4
+           2.4.1. Definition ..........................................4
+           2.4.2. Examples ...........................................12
+      2.5. Relevant Ancillary Documentation ..........................15
+      2.6. Identifier Uniqueness Considerations ......................15
+      2.7. Identifier Persistence Considerations .....................15
+      2.8. Process for Identifier Resolution .........................16
+      2.9. Rules for Lexical Equivalence .............................16
+      2.10. Conformance with URN Syntax ..............................17
+      2.11. Validation Mechanism .....................................17
+      2.12. Scope ....................................................17
+   3. Namespace Considerations .......................................17
+   4. Community Considerations .......................................18
+   5. IANA Considerations ............................................20
+   6. Security Considerations ........................................20
+   7. References .....................................................21
+      7.1. Normative References ......................................21
+      7.2. Informative References ....................................21
+   Appendix A. Alternative Naming Schemes ............................23
+   Appendix B. ABNF Definition of Namespace ID = "iso"
+               (Informative) .........................................24
+
+1.  Introduction
+
+   The International Organization for Standardization (ISO) was created
+   by international agreement in 1947.  ISO is a network of the national
+   standards institutes of many countries, on the basis of one member
+   per country, with a Central Secretariat in Geneva, Switzerland, that
+   coordinates the system.  ISO acts as a bridging organization in which
+   a consensus can be reached on solutions that meet both the
+   requirements of business and the broader needs of society, such as
+   the needs of stakeholder groups like consumers and users.
+
+   Further information is provided at http://www.iso.org/iso/about.htm.
+
+   The core mission of ISO is to develop technical standards
+   constituting technical agreements that provide the framework for
+   compatible technology worldwide.  ISO standards contribute to making
+   the development, manufacturing, and supply of products and services
+   more efficient, safer, and cleaner.  They make trade between
+   countries easier and fairer.
+
+
+
+Goodwin & Apel               Informational                      [Page 2]
+
+RFC 5141                     ISO URN Schema                   March 2008
+
+
+   Every participating ISO member institute (full members) has the right
+   to take part in the development of any standard that it judges to be
+   important to its country's economy.  No matter what the size or
+   strength of that economy, each participating member in ISO has one
+   vote.  ISO's activities are thus carried out in a democratic
+   framework where each country is on an equal footing to influence the
+   direction of ISO's work at the strategic level, as well as the
+   technical content of its individual standards.  Although the ISO
+   standards are voluntary, the fact that they are developed in response
+   to market demand, and are based on consensus among the interested
+   parties, ensures widespread applicability of the standards.
+   Consensus, like technology, evolves and ISO takes account of both
+   evolving technology and evolving interests by requiring a review of
+   its standards at least every five years to decide whether they should
+   be maintained, updated, or withdrawn.
+
+   ISO publishes International Standards and other technical
+   specifications that are cited in the definitions of required or
+   expected practices in many industries in many nations.  These
+   specifications contain dictionaries of standard terms, catalogues of
+   reference values, definitions of formal languages, formal schemata
+   for information capture and exchange, specifications for standard
+   practices, and other information resources of general use to
+   international trade and industry.  ISO wishes to create and manage
+   globally unique, persistent, location-independent identifiers for
+   these resources.
+
+   This specification defines the syntax for URNs that identify
+   documents developed by the International Organization for
+   Standardization (ISO) in accordance with the standards development
+   procedures defined in the ISO/IEC Directives, Part 1 [ISODIR-1] and
+   the ISO supplement [ISODIR-S] and processed by the ISO Central
+   Secretariat.  The syntax extends to identify document metadata and
+   resources related to these documents or otherwise associated with
+   them.  It does not extend to products derived from these documents
+   and published by ISO (e.g., handbooks, compendia) or documents at or
+   below the Technical Committee level.  Revisions of this specification
+   may define syntax for URNs in this namespace that identify other ISO
+   objects, when the ISO community defines a requirement for such
+   identifiers.
+
+
+
+
+
+
+
+
+
+
+
+Goodwin & Apel               Informational                      [Page 3]
+
+RFC 5141                     ISO URN Schema                   March 2008
+
+
+2.  Specification Template
+
+2.1.  Namespace ID
+
+   "iso"
+
+2.2.  Registration Information
+
+   Version 2.1
+   Date: 2007-12-13
+
+2.3.  Declared Registrant of the Namespace
+
+   J. Goodwin
+   ISO Central Secretariat
+   International Organization for Standardization (ISO)
+   Case Postale 56
+   CH-1211 Geneva 20
+   Switzerland
+
+   E-mail: goodwin@iso.org
+
+2.4.  Declaration of Structure
+
+2.4.1.  Definition
+
+   The Namespace Specific Strings (NSSs) of all URNs assigned by ISO
+   will conform to the syntax defined in Section 2.2 of [RFC2141].
+
+   The NSS has the following ABNF [RFC5234] specification:
+
+   NSS           = std-nss
+
+      All URNs conforming to this specification begin the NSS with the
+      prefix "std:" to denote the restriction to documents developed by
+      the ISO standards development procedures as defined in the ISO/IEC
+      Directives, Part 1 [ISODIR-1] and the ISO Supplement [ISODIR-S].
+      Prefixes that identify ISO objects of other kinds may be defined
+      in future revisions of this specification.
+
+      std-nss       = "std:" docidentifier *supplement *docelement
+                      [addition]
+
+      The prefix "std:" distinguishes an <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]
+