idnits 2.17.1 draft-goodwin-iso-urn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1240. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1247. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1253. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 13, 2007) is 5979 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISODIR-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISODIR-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISODIR-S' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISOGUIDE69' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO639-1' ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 4646 (Obsoleted by RFC 5646) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Goodwin 3 Internet-Draft H. Apel 4 Intended status: Standards Track ISO 5 Expires: June 15, 2008 December 13, 2007 7 A Uniform Resource Name (URN) Namespace for the International 8 Organization for Standardization (ISO) 9 draft-goodwin-iso-urn-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 15, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes a Uniform Resource Name Namespace 43 Identification (URN NID) for the International Organization for 44 Standardization (ISO). This URN NID is intended for use for the 45 identification of persistent resources published by the ISO standards 46 body (including documents, document metadata, extracted resources 47 such as standard schemata and standard value sets, and other 48 resources). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Specification Template . . . . . . . . . . . . . . . . . . . . 5 54 2.1. Namespace ID . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.2. Registration Information . . . . . . . . . . . . . . . . . 5 56 2.3. Declared registrant of the namespace . . . . . . . . . . . 5 57 2.4. Declaration of structure . . . . . . . . . . . . . . . . . 5 58 2.4.1. Definition . . . . . . . . . . . . . . . . . . . . . . 5 59 2.4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 13 60 2.5. Relevant ancillary documentation . . . . . . . . . . . . . 16 61 2.6. Identifier uniqueness considerations . . . . . . . . . . . 16 62 2.7. Identifier persistence considerations . . . . . . . . . . 16 63 2.8. Process for identifier resolution . . . . . . . . . . . . 16 64 2.9. Rules for lexical equivalence . . . . . . . . . . . . . . 17 65 2.10. Conformance with URN Syntax . . . . . . . . . . . . . . . 17 66 2.11. Validation mechanism . . . . . . . . . . . . . . . . . . . 17 67 2.12. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 3. Namespace Considerations . . . . . . . . . . . . . . . . . . . 19 69 4. Community Considerations . . . . . . . . . . . . . . . . . . . 21 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 75 Appendix A. Alternative naming schemes . . . . . . . . . . . . . 26 76 Appendix B. ABNF definition of namespace ID = "iso" 77 (informative) . . . . . . . . . . . . . . . . . . . . 28 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 79 Intellectual Property and Copyright Statements . . . . . . . . . . 32 81 1. Introduction 83 The International Organization for Standardization (ISO) was created 84 by international agreement in 1947. ISO is a network of the national 85 standards institutes of many countries, on the basis of one member 86 per country, with a Central Secretariat in Geneva, Switzerland, that 87 coordinates the system. ISO acts as a bridging organization in which 88 a consensus can be reached on solutions that meet both the 89 requirements of business and the broader needs of society, such as 90 the needs of stakeholder groups like consumers and users. 92 (Further information is provided at 93 http://www.iso.org/iso/about.htm.) 95 The core mission of ISO is to develop technical standards 96 constituting technical agreements which provide the framework for 97 compatible technology worldwide. ISO standards contribute to making 98 the development, manufacturing and supply of products and services 99 more efficient, safer and cleaner. They make trade between countries 100 easier and fairer. 102 Every participating ISO member institute (full members) has the right 103 to take part in the development of any standard which it judges to be 104 important to its country's economy. No matter what the size or 105 strength of that economy, each participating member in ISO has one 106 vote. ISO's activities are thus carried out in a democratic 107 framework where each country is on an equal footing to influence the 108 direction of ISO's work at the strategic level, as well as the 109 technical content of its individual standards. Although ISO 110 standards are voluntary, the fact that they are developed in response 111 to market demand, and are based on consensus among the interested 112 parties, ensures widespread applicability of the standards. 113 Consensus, like technology, evolves and ISO takes account both of 114 evolving technology and of evolving interests by requiring a review 115 of its standards at least every five years to decide whether they 116 should be maintained, updated or withdrawn. 118 ISO publishes International Standards and other technical 119 specifications that are cited in the definitions of required or 120 expected practices in many industries in many nations. These 121 specifications contain dictionaries of standard terms, catalogues of 122 reference values, definitions of formal languages, formal schemata 123 for information capture and exchange, specifications for standard 124 practices, and other information resources of general use to 125 international trade and industry. ISO wishes to create and manage 126 globally unique, persistent, location-independent identifiers for 127 these resources. 129 This specification defines the syntax for URNs that identify 130 documents developed by the International Organization for 131 Standardization (ISO) in accordance with the standards development 132 procedures defined in the ISO/IEC Directives, Part 1 [ISODIR-1] and 133 the ISO supplement [ISODIR-S] and processed by the ISO Central 134 Secretariat. The syntax extends to identify document metadata and 135 resources related to these documents or otherwise associated with 136 them. It does not extend to products derived from these documents 137 and published by ISO (e.g. handbooks, compendia) or documents at or 138 below the Technical Committee level. Revisions of this specification 139 may define syntax for URNs in this namespace that identify other ISO 140 objects, when the ISO community defines a requirement for such 141 identifiers. 143 2. Specification Template 145 2.1. Namespace ID 147 "iso" 149 2.2. Registration Information 151 Version 2.1 152 Date: 2007-12-13 154 2.3. Declared registrant of the namespace 156 J. Goodwin 157 ISO Central Secretariat 158 International Organization for Standardization (ISO) 159 Case Postale 56 160 CH-1211 Geneva 20 161 Switzerland 163 E-mail: goodwin@iso.org 165 2.4. Declaration of structure 167 2.4.1. Definition 169 The Namespace Specific Strings (NSS) of all URNs assigned by ISO will 170 conform to the syntax defined in section 2.2 of [RFC2141]. 172 The NSS has the following ABNF [RFC4234] specification: 174 NSS = std-nss 176 All URNs conforming to this specification begin the NSS with the 177 prefix "std:", to denote the restriction to documents developed by 178 the ISO standards development procedures as defined in the ISO/IEC 179 Directives, Part 1 [ISODIR-1] and the ISO Supplement [ISODIR-S]. 180 Prefixes that identify ISO objects of other kinds may be defined 181 in future revisions of this specification. 183 std-nss = "std:" docidentifier *supplement *docelement 184 [addition] 186 The prefix "std:" distinguishes an . An 187 identifies the ISO document that is designated by the 188 , as extended or modified by any identified 189 . (An that identifies all parts of a 190 multipart ISO document is a special case as described under the 191 element .) If the contains an 192 element, the NSS identifies a resource extracted from the ISO 193 document or otherwise associated with it (see below). 195 docidentifier = originator [":" type] ":" docnumber [":" partnumber] 196 [[":" status] ":" edition] 197 [":" docversion] [":" language] 199 provides the complete identification of an ISO 200 document. Each of its component elements is described below. 202 originator = "iso" / "iso-iec" / "iso-cie" / "iso-astm" / 203 "iso-ieee" / "iec" 205 is the organization (usually an international body) 206 from which a document emanates. 208 Current values: 210 iso = International Organization for Standardization 212 iec = International Electrotechnical Commission (IEC), or 213 Commission Electrotechnique Internationale 215 iso-iec = jointly developed by ISO and IEC 217 iso-cie = jointly developed by ISO and the Commission 218 Internationale d'Eclairage (CIE) 220 iso-astm = jointly developed by ISO and the American Society for 221 Testing and Materials International (ASTM) 223 iso-ieee = jointly developed by ISO and the Institute for 224 Electrical and Electronics Engineers (IEEE) 226 Revisions of this specification may define additional values. 228 type = "data" / "guide" / "isp" / "iwa" / 229 "pas" / "r" / "tr" / "ts" / "tta" 231 designates the ISO deliverable type. If the element 232 is not present, the classification is "international standard". 233 Other current values: 235 data = Data (document type no longer published) 236 guide = Guide 238 isp = International Standardized Profile 240 iwa = International Workshop Agreement 242 pas = Publicly Available Specification 244 r = Recommendation (document type no longer published) 246 tr = Technical Report 248 ts = Technical Specification 250 tta = Technology Trends Assessment 252 docnumber = DIGITS 254 is the reference number assigned to the document by 255 ISO and/or IEC. An ISO document may comprise a single document, 256 or two or more separate parts each of which is identified by 257 . 259 partnumber = "-" 1*( DIGIT / ALPHA / "-" ) 261 is the reference number that identifies a part of a 262 multipart standard. 264 Where it is required to refer to a multipart ISO document in its 265 entirety, this can be designated by omitting the 266 element. However, this precludes the possibility of using any 267 further elements except . 269 _NOTE_ The option to refer to a multipart ISO document by omitting 270 the element has been included to align with the 271 provision in the ISO/IEC Directives, Part 2, 2004 [ISODIR-2] 272 subclause 6.2.2 of making an undated reference to all parts of an 273 ISO document. It is only permissible to use this option where the 274 URN is referring to a multipart ISO document in its entirety. 275 Since the use of this option precludes the designation of the 276 elements and , it is implicit that the URN needs 277 to remain valid irrespective of any future changes to the 278 multipart document (see the rules for undated references given in 279 the ISO/IEC Directives, Part 2, 2004 [ISODIR-2] subclause 280 6.6.7.5.2). This shall be taken into consideration in the use 281 (and maintenance) of any URN specification employing this option. 283 _NOTE_ In the case where the multipart document comprises 284 different types of ISO deliverable, the of the core part 285 (usually part 1) applies. See the example "Reference to a 286 resource related to all parts of a multipart document". 288 Except for the case where it is required to refer to a multipart 289 document in its entirety, the element is required if 290 the identified resource is a part of an ISO document. Otherwise, 291 this element is not used. 293 status = ( "draft" / "cancelled" ) / stage 295 indicates the publication status of the document. When 296 the element is not present, the NSS refers to a published 297 document. Other values: 299 draft = document that has not yet been accepted for 300 publication by international ballot 302 cancelled = document that has been deleted or withdrawn 304 stage = "stage-" stagecode ["." iteration] 306 indicates the stage code and iteration of the document. 308 stagecode = DIGIT DIGIT "." DIGIT DIGIT 310 is the harmonized stage code in accordance with ISO 311 Guide 69:1999, "Harmonized Stage Code system (Edition 2) -- 312 Principles and guidelines for use" [ISOGUIDE69]. 314 iteration = "v" DIGITS 316 is a sequential number which refers to a specific 317 iteration of the project's lifecycle through the designated stage. 319 If no is specified the reference is to the highest 320 iteration available for the specified stagecode. 322 _NOTE_ In the ISO Central Secretariat project management database 323 the is referred to as the "project version". 325 edition = "ed-" DIGITS 327 designates a specific edition of the document. (DIGITS 328 is the (sequential) edition number.) If no is 329 specified, the NSS refers to the latest edition. 331 docversion = "v" (simpleversion / isoversion) 333 simpleversion = DIGITS 335 designates the version number of a document's 336 . It is altered by correction (corrected version; 337 Technical Corrigendum) or amendment (Amendment; Addendum) and is 338 distinct from a revision, which changes the edition number. 340 In the , the first version published is 1, and each 341 subsequent correction or amendment increases the version number by 342 1. 344 If no is specified, the reference is to the highest 345 version number available for the denoted . 347 Current values of : 349 1 - first version published 351 2 - corrected version published 353 isoversion = baseversion *includedsuppl 355 baseversion = DIGITS 357 includedsuppl = "-" suppltype supplnumber [ "." supplversion ] 359 An can be linked to a simpleversion by defining an 360 existing simpleversion as baseversion and listing all the 361 elements (corrections and amendments) incorporated 362 into that version. 364 Examples for the (internal ISO version) scheme: 366 1 = first version of standard 368 1-amd1.v1 = first version of standard incorporating first 369 version of Amendment 1 371 1-amd1.v1-amd2.v1 = first version of standard incorporating 372 first version of Amendment 1 and first version of Amendment 2 374 1-amd1.v2-amd2.v1-amd3 = first version of standard 375 incorporating corrected version of Amendment 1, first version 376 of Amendment 2, and highest version of Amendment 3 377 1-cor3 = first version of standard incorporating highest 378 version of Technical Corrigendum 3 380 1-amd1-cor3 = first version of standard incorporating highest 381 version of Amendment 1 and highest version of Technical 382 Corrigendum 3 384 language = monolingual / bilingual / trilingual 386 monolingual = "en" / "fr" / "ru" / "es" / "ar" 388 bilingual = "en,fr" / "en,ru" / "fr,ru" 390 trilingual = "en,fr,ru" 392 designates the official ISO language(s), or the 393 language of an official translation, in which the document 394 (object) is processed and published by ISO (excluding languages 395 which constitute only specific elements of the content). The 396 value is one or more alpha-2 codes, each of which designates a 397 language, as specified in ISO 639-1 [ISO639-1]. If no language 398 element is specified, is assumed. 400 _NOTE_ Although [ISO639-1] recommends that language codes be 401 written in lowercase this ABNF definition allows the use of 402 uppercase language codes because in ABNF [RFC4234], terminal 403 symbols defined as literal strings are explicitly case- 404 insensitive. This case distinction does not carry any meaning 405 (see Section 2.9) and it is recommended to use language codes in 406 lowercase. For additional information about the usage of language 407 tags in information objects see [RFC4646]. 409 supplement = ":" suppltype ":" supplnumber 410 [":" supplversion ] [":" language ] 412 suppltype = "amd" / "cor" / "add" 414 supplnumber = DIGITS 416 supplversion = "v" DIGITS 418 designates a technical alteration of or addition to 419 an ISO standard that does not result in a new or 420 . Each may be one of the three types, 421 designated by : 423 amd = Amendment -- a document that alters and/or adds to 424 previously agreed technical provisions in an existing ISO 425 document; an amendment is subject to acceptance by ballot in 426 accordance with the ISO/IEC Directives, Part 1, 2004 427 [ISODIR-1] subclause 2.10.3 429 cor = Technical Corrigendum -- a document that corrects a 430 technical error or ambiguity, or updates the ISO document in 431 such a way that the modification has no effect on the 432 technical normative elements; a Technical Corrigendum is not 433 balloted -- see the ISO/IEC Directives, Part 1, 2004 434 [ISODIR-1] subclause 2.10.2 436 add = Addendum -- (document type no longer published) Addenda were 437 documents that changed (by correction, addition or deletion) 438 the technical requirements of an ISO document; an addendum 439 was subject to acceptance by ballot in accordance with the 440 ISO/IEC Directives, Part 1. (Addenda are included in this 441 RFC because some of them are still valid.) 443 Supplements are numbered consecutively per ISO document, and 444 within each supplement type. 446 identifies the number of the supplement. 448 designates the version of a published supplement. 449 At present only two versions are used in practice: when a 450 supplement is published it is version 1. If that supplement is 451 subsequently corrected by issuing a corrected version, as 452 designated by the term "Corrected" on the cover page together with 453 a date, the corrected version is version 2. 455 The language of a supplement can be different from that of the 456 document. For example, a supplement may apply to only one of the 457 languages of a bilingual document. For such cases, the language 458 of a supplement can be identified using the element 459 defined above. The interpretation is the same, except that it 460 applies only to the supplement. 462 docelement = ":" ( "clause" / "figure" / "table" / "term" ) ":" 463 elementnumber / elementrange 464 *( "," elementnumber / elementrange ) 466 elementnumber = ( ALPHA / DIGITS ) *( "." DIGITS ) 467 elementrange = elementnumber "-" elementnumber 469 identifies one or more numbered subdivisions of a 470 document. Types of numbered subdivision are specified in the ISO/ 471 IEC Directives, Part 2 [ISODIR-2]. This RFC currently specifies 472 forms for reference to clauses, figures, tables and terms only. 473 It does not provide for reference to subfigures. Revisions of 474 this specification may define additional values. 476 represents the selection of one or more clauses or 477 subclauses of the document.
represents the selection of 478 one or more figures of the document. represents the 479 selection of one or more tables of the document. represents 480 the selection of one or more terms of the document 482 designates a numbered subdivision in a document, 483 where the type of subdivision is identified by the literal 484 "clause", "figure", "table" or "term". When the first character 485 of is a digit, the reference is to the subdivision 486 designated by that digit string and by any additional digit 487 strings separated by periods. When the first character of 488 is alphabetical, the reference is to the 489 corresponding Annex, and to the subdivisions designated by 490 additional digit strings. 492 The form HYPHEN designates a range 493 of subdivisions and the form COMMA 494 a list. A list can contain ranges. 496 addition = techdefined / isodefined 498 techdefined = ":tech" *techelement 500 techelement = 502 isodefined = 504 is an additional element of the NSS intended to 505 identify a representation of an ISO document, an extract from an 506 ISO document, or some related information set, as a resource in 507 its own right. 509 represents an associated or embedded resource 510 defined by the committee that develops or maintains the identified 511 document. All such begin with the prefix ":tech". 513 represents associated or embedded resources defined 514 by the ISO Central Secretariat. The definition of an 515 element beginning with any symbol other than is reserved to 516 the ISO Central Secretariat. 518 The syntax of the element is not specified in this RFC. 519 Specific syntax for this element will be specified as needed by 520 the ISO Central Secretariat, or by the individual Committee that 521 has the responsibility for developing or maintaining the 522 identified document. It is necessary that these definitions 523 comply with the rules for lexical equivalence specified in 524 Section 2.9 and take into account the process for identifier 525 resolution as discussed in Section 2.8. 527 DIGITS = DIGIT *DIGIT 529 DIGIT = %x30-39 ; 0-9 531 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 533 Basics of the ABNF notation used : 535 " " literals (terminal character strings); 536 terms not in quotes are non-terminals 538 / alternatives 540 [] indicates an optional rule 542 () indicates a sequence group, used as a single alternative or as a 543 single repeating group 545 * indicates that the following term or group can repeat at 546 least and at most times; default values are 0 and 547 infinity respectively 549 ; comment 551 2.4.2. Examples 553 o Language handling: 555 urn:iso:std:iso:9999:-1:ed-1:en 556 refers to the 1st edition of ISO 9999-1, in English 558 urn:iso:std:iso:9999:-1:ed-1:en,fr 559 refers to the 1st edition of ISO 9999-1, in English/French 560 (bilingual document) 562 o Originators/document type: 564 urn:iso:std:iso-iec:tr:9999:-1:ed-1:en 565 refers to the 1st edition of ISO/IEC TR 9999-1, in English 567 o Status: 569 urn:iso:std:iso-iec:9075:-3:cancelled:ed-2:en 570 urn:iso:std:iso-iec:9075:-3:stage-95.99:ed-2:en 571 both refer to the cancelled 2nd edition of ISO/IEC 9075-3, in 572 English 574 urn:iso:std:iso-iec:9075:-3:draft:ed-4:en 575 urn:iso:std:iso-iec:9075:-3:stage-30.60:ed-4:en 576 both refer to the draft 4th edition of ISO/IEC 9075-3, in English 578 urn:iso:std:iso:128:-20:en 579 urn:iso:std:iso:128:-20:stage-90.20:ed-1:en 580 both refer to the published (90.20 = under 2nd periodic review) 581 1st edition of ISO 128-20, in English 583 urn:iso:std:iso:128:-71:cancelled:ed-1:en 584 urn:iso:std:iso:128:-71:stage-30.98.v2:ed-1:en 585 both refer to the cancelled (30.98 = project deleted) 1st edition 586 of ISO 128-71, in English; the second example refers specifically 587 to the 2nd iteration (projectversion) at stage 30 589 o Non-numeric part number: 591 urn:iso:std:iso:9999:-A02:ed-1:en 592 refers to the 1st edition of ISO 9999-A02, in English 594 o Reference to a resource related to all parts of a multipart 595 document: 597 urn:iso:std:iso:20022:tech:xsd:camt.001.001.01 598 refers to a "techdefined" resource (i.e. a resource defined by the 599 committee that develops or maintains the identified document) 600 associated with ISO 20022 in its entirety; in this example the 601 techdefined part comprises ":xsd:camt.001.001.01" 603 _NOTE_ At the time of drafting of this schema, ISO 20022 comprises 604 5 parts: parts 1 and 2 are International Standards; parts 3 to 5 605 are Technical Specifications. Therefore the 606 "international standard" is used in the URN. 608 o Docversion handling: 610 urn:iso:std:iso:9999:-1:ed-1:v2:en 611 refers to the corrected English version of the 1st edition of ISO 612 9999-1 614 urn:iso:std:iso:9999:-1:ed-1:v1-amd1:en 615 refers to the version comprising the 1st edition of ISO 9999-1, 616 incorporating the latest version of Amendment 1, in English 618 urn:iso:std:iso:9999:-1:ed-1:v1:en,fr:amd:1:v2:en 619 refers to the 2nd version of Amendment 1, in English, which amends 620 the 1st version of edition 1 of ISO 9999-1, in English/French 621 (bilingual document) 623 urn:iso:std:iso:9999:-1:ed-1:v1-amd1.v1:en,fr:amd:2:v2:en 624 (isoversion scheme) 625 refers to the corrected version of Amendment 2, in English, which 626 amends the document comprising the 1st version of edition 1 of ISO 627 9999-1 incorporating the 1st version of Amendment 1, in English/ 628 French (bilingual document) 630 urn:iso:std:iso:5817:ed-2:v2:en:cor:1:en 631 refers to the 1st version of Technical Corrigendum 1, in English, 632 which amends the corrected version of edition 2 of ISO 5817, in 633 English 635 o Supplement handling: 637 urn:iso:std:iso:9999:-1:ed-2:en:amd:1 638 refers to Amendment 1 to the 2nd edition of ISO 9999-1, in English 640 urn:iso:std:iso:9999:-1:ed-2:en:amd:1:v2 641 refers to the corrected version of Amendment 1 to the 2nd edition 642 of ISO 9999-1, in English 644 urn:iso:std:iso:9999:1:ed-2:en,fr:amd:2:en 645 refers to Amendment 2 in English to the 2nd edition of ISO 9999-1, 646 in English/French (bilingual document) 648 urn:iso:std:iso:9999:-1:ed-2:en:amd:1:cor:1 649 refers to Corrigendum 1 to Amendment 1 to the 2nd edition of ISO 650 9999-1, in English 652 o Docelement handling: 654 urn:iso:std:iso:105:-c12:ed-1:en:clause:a.1,a.2 655 urn:iso:std:iso:105:-c12:ed-1:en:clause:a.1-a.2 656 both refer to clauses A.1 and A.2 in the 1st edition of ISO 105- 657 C12, in English 658 urn:iso:std:iso:9999:-1:ed-1:v1- 659 amd1.v1:en,fr:amd:2:v2:en:clause:3.1,a.2-b.9 (isoversion scheme) 660 refers to (sub)clauses 3.1 and A.2 to B.9 in the corrected version 661 of Amendment 2, in English, which amends the document comprising 662 the 1st version of edition 1 of ISO 9999-1 incorporating the 1st 663 version of Amendment 1, in English/French (bilingual document) 665 urn:iso:std:iso:9999:-1:ed-2:en:amd:1:term:3.2,3.3,3.4.1- 666 3.4.4,3.12 667 refers to the terms 3.2, 3.3, 3.4.1 to 3.4.4, and 3.12 in 668 Amendment 1 to the 2nd edition of ISO 9999-1, in English 670 2.5. Relevant ancillary documentation 672 ISO/IEC Directives, Part 1 [ISODIR-1] and Part 2 [ISODIR-2], and ISO 673 supplement [ISODIR-S]. 675 2.6. Identifier uniqueness considerations 677 Assignment of URNs for documents in the requested namespace will be 678 managed by the ISO Central Secretariat, which will ensure that the 679 assigned URNs are consistent with the ISO Directives for unique 680 identification of ISO documents. 682 Assignment of URNs for Technical Committee resources related to ISO 683 documents will be managed by the Technical Committees developing or 684 maintaining those documents. As indicated above, each such URN will 685 extend the URN for the containing document via the element 686 . The responsibility of the Technical Committee will 687 therefore be to ensure the uniqueness of the techdefined 688 element that constitutes the identifier for the resource within the 689 document namespace, and thus the uniqueness of the overall resource 690 identifier within the requested namespace. 692 2.7. Identifier persistence considerations 694 Assigned URNs will not be reused and will remain valid beyond the 695 lifecycle of the referenced resources. However, it should be noted 696 that although the URNs remain valid, the status of the referenced 697 resource may change. 699 2.8. Process for identifier resolution 701 Resolving document identifiers: 703 This schema has been developed with the intent that a URN 704 identifying an ISO document can be transformed to a valid http URI 705 by replacing the requested URN namespace prefix ("iso") and the 706 "std:" prefix with the domain name "standards.iso.org" and 707 replacing all occurrences of ":" within the identifier with "/" 708 and converting characters to lower case. (ISO is planning to 709 develop a website implementation to support these URIs.) 711 Examples: 713 urn:iso:std:iso:9999:-1:ed-1:en: corresponds to 714 http://standards.iso.org/iso/9999/-1/ed-1/en/ 716 urn:iso:std:iso-iec:tr:9999:-1:ed-1:en: corresponds to 717 http://standards.iso.org/iso-iec/tr/9999/-1/ed-1/en/ 719 urn:iso:std:iso:9999:-1:ed-2:en,fr:amd:2: corresponds to 720 http://standards.iso.org/iso/9999/-1/ed-2/en,fr/amd/2/ 722 Resolving identifiers for resources: 724 For URNs in the requested namespace that refer to additional 725 resources related to ISO documents, the ISO Central Secretariat 726 will specify the resolution procedure at the time it defines the 727 syntax for the corresponding to the . In most 728 cases, those resources will be maintained on an ISO website, as 729 extensions to the HTTP URIs described above. 731 2.9. Rules for lexical equivalence 733 URNs are lexically equivalent if they are octet-by-octet equal after 734 the following preprocessing: 736 1. normalize the case of the leading "urn:" token 738 2. normalize the case of the NID 740 3. normalize the case of any %-escaping 742 4. normalize the case of all elements 744 Further information is specified in [RFC2141], clause 5. 746 2.10. Conformance with URN Syntax 748 No special considerations. 750 2.11. Validation mechanism 752 None specified. 754 2.12. Scope 756 Global. 758 3. Namespace Considerations 760 The ISO specific requirements are as follows: 762 o globally unique, persistent identifiers 764 o location-independent identifiers 766 o human-interpretable identifiers 768 o a scheme applicable to paper documents as well as machine-readable 769 documents 771 o a scheme applicable to conceptual documents and explicit forms of 772 documents 774 o a scheme applicable to resources extracted from documents 776 o a scheme applicable to "metadata" associated with documents 778 o a scheme in which the identifier assignment is managed by the ISO 779 Central Secretariat. 781 Location-independence: Because the publication of ISO standards is a 782 complex arrangement involving multiple development organizations and 783 national standards institutes, a given ISO document may be available 784 in a number of forms from a number of sources. This makes it 785 important to have a document identifier that is global in scope, 786 widely and uniformly used, and independent of the text source used by 787 any given reference. 789 Human-interpretable: Many, perhaps most, references to documents 790 appear in text generated by human authors. It is important that an 791 author familiar with the scheme be able to generate a correct URN for 792 a document for which the author has the ISO reference (or document 793 identifier). Conversely, it is important that a reader unfamiliar 794 with the scheme be able to identify the URN as a reference to an ISO 795 document, particularly an ISO standard, and also to recognize 796 identifiers for forms, languages, or metadata sets. 798 Paper documents: Older ISO standards that are commonly used as 799 industrial references exist only in paper form or in earlier machine- 800 readable forms that are not commonly used on the Internet. It is 801 important to have a document identifier scheme that extends to these 802 resources as well. (In fact, many of these have been converted to 803 Internet forms, and others are being converted, but it is important 804 that the identifier be independent of the form in which the document 805 can be obtained at any given time.) 806 Conceptual documents vs. representation forms: Because ISO documents 807 are regularly maintained and re-published in multiple forms, it is 808 important to have document identifiers that denote the conceptual 809 document, without regard to publication form. At the same time, it 810 is necessary for certain types of use to be able to refer to specific 811 editions, or specific publication forms (for example, editions in 812 different languages, or to PDF or HTML versions). This URN 813 specification allows for the identification of these different types 814 of use in the part of the element. 816 Document extracts: ISO standards may contain formal specifications in 817 machine-processable languages, or formal specifications that also 818 have representations in machine-processable languages. It is useful 819 to be able to extract these specifications in machine-processable 820 form as separate resources, and therefore it is necessary to give 821 these "extracted resources" global identifiers derived from the 822 document identifier using a consistent identification scheme. 824 Document metadata: Certain uses of documents and document text, 825 primarily bibiliographic, also extract information from the 826 documents, and that information, commonly called "metadata", is 827 organized in machine-readable forms conforming to other standards. 828 These metadata sets then become resources in their own right. It is 829 important to give them URN identifiers consistent with the document 830 identification scheme. 832 4. Community Considerations 834 The ISO community is broad in two dimensions. In one dimension, its 835 documents are developed and used in a large variety of industries and 836 professions: natural sciences, manufacturing, construction, 837 transportation, information technology, social sciences, etc. In the 838 other dimension, it is a community of expert developers, standards 839 managers, publishers, professional users and consumers. And Internet 840 information technologies are a part of common professional practice 841 in all of these areas in both dimensions. 843 ISO standards are cited in business agreements, in professional 844 publications, in product descriptions, and in standards development 845 and publication activities. When these citations appear in 846 electronic form, the references must be unambiguous. 848 The information technology community is itself very active in the 849 development and use of standards, and many ISO publications are 850 developed by and for that community. When an Internet information 851 exchange uses a form specified in an ISO document, or a terminology 852 defined in an ISO document, it is often necessary to identify that 853 ISO specification in the envelope surrounding the exchange. That 854 identification should use a formal unambiguous identifier in a form 855 readily recognized by the receiving software, and possibly by the 856 ultimate human recipient of the information. 858 In order to facilitate the use of existing and emerging Internet 859 technologies for all of these purposes, URNs conforming to [RFC2141] 860 represent the most useful form of formal globally unambiguous 861 identifier. The use of a managed namespace for such identifiers, 862 following a consistent scheme for identifying ISO documents and their 863 derivatives would be of significant benefit to the entire ISO 864 community. 866 It would give professional users in many industries a standard 867 form for electronic reference to ISO standards in HTML, XML, PDF, 868 etc., documents. 870 It would give software developers a standard form for reference to 871 ISO standard protocols, schemata, languages, data sets, etc. 873 It would give standards developers a standard form for reference 874 to other ISO publications in various stages of development. And 875 it would give them a standard form for creating identifiers for 876 machine-readable information sets contained in, or derived from, 877 the specifications. 879 It would give standards managers and publishers a formal uniform 880 scheme for reference to specific publications, editions and 881 versions of ISO documents. 883 While the assignment of identifiers under this scheme is managed by 884 the ISO Central Secretariat, the processes by which the identified 885 objects arise and acquire such identifiers are the result of 886 agreements made by the member bodies. Every such project is 887 initiated by one member body and reviewed and voted on by the others. 888 Every accepted project is open to participation by any member body, 889 and in fact, participation by a certain minimum number (usually 5) of 890 member bodies is required for acceptance of most projects. In 891 general, the member bodies are open professional and industrial 892 organizations reflecting broad expertise and national interest. 894 It should be noted that ISO documents in draft state are not usually 895 made available outside the ISO standards development community. 896 Making them available to professionals outside of the process might 897 well mislead the recipients into premature adoption of practices that 898 are not yet completely specified or have not yet achieved consensus, 899 and therefore may well change. 901 It should also be noted that ISO documents are not, in general, 902 freely available over the Internet. Rather there are complex 903 agreements between ISO and its member institutes as to the rights to 904 the publications and the corresponding fees that may be charged for 905 paper or electronic copies of various editions. Some ISO documents 906 are freely available, and some are freely available in certain forms. 907 In general, derivatives of ISO documents (schemata, metadata sets, 908 etc.) are freely available over the Internet in the appropriate 909 machine-readable forms. A URL associated with a URN in the requested 910 namespace may therefore lead directly to a machine-readable copy of 911 the text of the document or derivative, or it may lead to a site that 912 can provide that text for a fee, or it may lead to a site that can 913 only sell a paper copy of the document. Bearing in mind that ISO is 914 a network of otherwise independent institutes, this behaviour is 915 simply a property of the ISO community. 917 Finally, it should be noted that, for many purposes, reference to the 918 ISO standard is what is required, and only the product engineer or 919 software tool builder actually needs access to the text. This 920 request is based on the need to standardize the form of reference, 921 not the means of access. 923 5. IANA Considerations 925 IANA is requested to assign a formal NID. 927 The ISO Central Secretariat will maintain a registry of the 928 permissible values for the elements comprising the NSS. Information 929 may be obtained from the following address: urn@iso.org. 931 6. Security Considerations 933 The ISO URN Namespace ID shares the security considerations outlined 934 in [RFC3406], but has no other known security considerations. 936 7. References 938 7.1. Normative References 940 [ISODIR-1] 941 International Organization for Standardization, 942 "Procedures for the technical work", ISO/IEC 943 Directives Part 1, Edition 5, 2004. 945 [ISODIR-2] 946 International Organization for Standardization, "Rules for 947 the structure and drafting of International Standards", 948 ISO/IEC Directives Part 2, Edition 5, 2004. 950 [ISODIR-S] 951 International Organization for Standardization, 952 "Procedures specific to ISO", ISO/IEC 953 Directives Supplement. 955 [ISOGUIDE69] 956 International Organization for Standardization, 957 "Harmonized Stage Code system (Edition 2) - Principles and 958 guidelines for use", ISO Guide 69:1999. 960 [ISO639-1] 961 International Organization for Standardization, "Codes for 962 the representation of names of languages - Part 1: Alpha-2 963 code", ISO 639-1:2002. 965 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 967 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 968 Specifications: ABNF", RFC 4234, October 2005. 970 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 971 "Uniform Resource Names (URN) Namespace Definition 972 Mechanisms", BCP 66, RFC 3406, October 2002. 974 7.2. Informative References 976 [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", 977 RFC 3061, February 2001. 979 [RFC3151] Walsh, N., Cowan, J., and P. Grosso, "A URN Namespace for 980 Public Identifiers", RFC 3151, August 2001. 982 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 983 Languages", BCP 47, RFC 4646, September 2006. 985 Appendix A. Alternative naming schemes 987 Before initiating this request, ISO attempted to find an existing or 988 currently proposed URN NID scheme that might be used instead of a 989 dedicated scheme. Two existing schemes were carefully considered, 990 because they clearly meet part of the requirements: 992 o The OID scheme, documented in [RFC3061] 994 o The PublicId scheme, documented in [RFC3151] 996 The OID scheme is derived from the joint ISO/ITU-T ASN.1 object- 997 identifier scheme specified in ISO/IEC 8824-1:2002 (original edition 998 1984; [RFC3061] cites the 1988 CCITT edition of the encoding rules in 999 ISO/IEC 8825). This standard assigned to ISO the registry authority 1000 for all identifiers in the { iso(1) } namespace, and therefore, ISO 1001 controls the registry of all identifiers beginning "oid:1:". And in 1002 fact, ISO has developed, and is using, an identification scheme under 1003 ASN.1 that meets most of the above requirements. ISO could clearly 1004 define a use of the OID scheme that would be adequate to meet all of 1005 its technical objectives, although it would further complicate the 1006 current ASN.1 scheme. 1008 The original intent of ISO 8824 was to permit both a human-readable 1009 form for the identifier, to maximize intuitive recognition, and an 1010 encoding that minimized the number of bits needed to communicate an 1011 OID value over a network. Regrettably, the encoding chosen in RFC 1012 3061 is much closer to the minimal bits encoding than to the human- 1013 readable one. The NSS for the OID scheme consists entirely of digits 1014 and punctuation. For example, the ASN.1 identifier 1015 { iso(1) standard(0) 7852 part(2) edition(3) } 1016 becomes: urn:oid:1:0:7852:2:3. 1018 This is difficult for a human reader or author to interpret. It is 1019 also easy to mistype, and the scheme contains no "check-digits", 1020 which makes it difficult to validate, leading to the propagation of 1021 URNS that are invalid or valid but erroneous. Finally, the all- 1022 numeric form conveys no hint of the name of the responsible 1023 organization and therefore no hint of any URL that might aid a human 1024 reader in interpreting the reference. The OID scheme makes all of 1025 the required identifiers technically possible and technically useable 1026 by software, but for all practical purposes, the OID URNs are useful 1027 only to software. 1029 The PublicId scheme is derived from SGML (ISO 8879:1986 and ISO 9070: 1030 1991) bibliographic catalogue forms. Narrowed to ISO publications, 1031 it is adequate for the unique global persistent identification of 1032 published documents, in both paper and machine-processable form. 1034 Importantly, the PublicId scheme does not have a "conceptual 1035 document" notion -- it identifies specific publications and editions. 1036 "Weak identification" could be used to implement the conceptual 1037 document concept, but the PublicId scheme does not document that 1038 interpretation. And in any case, the PublicId scheme does not extend 1039 to draft documents, which are often referenced in pilot 1040 implementations, to separate forms of a document, or to resources 1041 extracted from documents. It supports only those metadata elements 1042 that are defined in SGML. The scheme could be extended to do most of 1043 these, but the ISO-specific extensions would not in general extend to 1044 the much broader base of documents identified by PublicIds. (Version 1045 and edition management practices vary significantly across 1046 publishers, depending on their milieu.) Further, the ISO Central 1047 Secretariat could not and should not control the registry of such 1048 URNs. 1050 ISO therefore concluded that the alternative schemes are not adequate 1051 to meet the requirements of the ISO community. 1053 Whilst requesting a new namespace for ISO documents and their 1054 derivatives, ISO does not wish to discourage the use of these other 1055 identifiers for ISO publications. The PublicId form, in particular, 1056 is useful for referring to ISO publications in a larger bibliographic 1057 information space. 1059 Appendix B. ABNF definition of namespace ID = "iso" (informative) 1061 NSS = std-nss 1063 std-nss = "std:" docidentifier *supplement *docelement 1064 [addition] 1066 docidentifier = originator [":" type] ":" docnumber [":" partnumber] 1067 [[":" status] ":" edition] 1068 [":" docversion] [":" language] 1070 originator = "iso" / "iso-iec" / "iso-cie" / "iso-astm" / 1071 "iso-ieee" / "iec" 1073 ; iso = International Organization for 1074 Standardization 1076 ; iec = International Electrotechnical 1077 Commission (IEC), or Commission 1078 Electrotechnique Internationale 1080 ; iso-iec = jointly developed by ISO and IEC 1082 ; iso-cie = jointly developed by ISO and the 1083 Commission Internationale d'Eclairage 1084 (CIE) 1086 ; iso-astm = jointly developed by ISO and the 1087 American Society for Testing and 1088 Materials International (ASTM) 1090 ; iso-ieee = jointly developed by ISO and the 1091 Institute for Electrical and 1092 Electronics Engineers (IEEE) 1094 type = "data" / "guide" / "isp" / "iwa" / 1095 "pas" / "r" / "tr" / "ts" / "tta" 1097 ; data = Data (document type no longer published) 1099 ; guide = Guide 1101 ; isp = International Standardized Profile 1103 ; iwa = International Workshop Agreement 1104 ; pas = Publicly Available Specification 1106 ; r = Recommendation (document type no longer 1107 published) 1109 ; tr = Technical Report 1111 ; ts = Technical Specification 1113 ; tta = Technology Trends Assessment 1115 docnumber = DIGITS 1117 partnumber = "-" 1*( DIGIT / ALPHA / "-" ) 1119 status = ( "draft" / "cancelled" ) / stage 1121 ; draft = document that has not yet been 1122 accepted for publication by 1123 international ballot 1125 ; cancelled = document that has been deleted or 1126 withdrawn 1128 stage = "stage-" stagecode ["." iteration] 1130 stagecode = DIGIT DIGIT "." DIGIT DIGIT 1132 iteration = "v" DIGITS 1134 edition = "ed-" DIGITS 1136 docversion = "v" (simpleversion / isoversion) 1138 simpleversion = DIGITS 1140 ; 1 = first version published 1142 ; 2 = corrected version published 1144 isoversion = baseversion *includedsuppl 1146 baseversion = DIGITS 1148 includedsuppl = "-" suppltype supplnumber [ "." supplversion ] 1150 language = monolingual / bilingual / trilingual 1152 monolingual = "en" / "fr" / "ru" / "es" / "ar" 1154 bilingual = "en,fr" / "en,ru" / "fr,ru" 1156 trilingual = "en,fr,ru" 1158 supplement = ":" suppltype ":" supplnumber 1159 [":" supplversion ] [":" language ] 1161 suppltype = "amd" / "cor" / "add" 1163 ; amd = Amendment 1165 ; cor = Technical Corrigendum 1167 ; add = Addendum 1169 supplnumber = DIGITS 1171 supplversion = "v" DIGITS 1173 docelement = ":" ( "clause" / "figure" / "table" / "term" ) ":" 1174 elementnumber / elementrange 1175 *( "," elementnumber / elementrange ) 1177 elementnumber = ( ALPHA / DIGITS ) *( "." DIGITS ) 1179 elementrange = elementnumber "-" elementnumber 1181 addition = techdefined / isodefined 1183 techdefined = ":tech" *techelement 1185 techelement = 1187 isodefined = 1189 DIGITS = DIGIT *DIGIT 1191 DIGIT = %x30-39 ; 0-9 1193 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 1195 Authors' Addresses 1197 J. Goodwin 1198 International Organization for Standardization 1199 Case Postal 56 1200 Geneva 20 1211 1201 Switzerland 1203 Email: goodwin@iso.org 1204 URI: http://www.iso.org 1206 H. Apel 1207 International Organization for Standardization 1208 Case Postal 56 1209 Geneva 20 1211 1210 Switzerland 1212 Email: apel@iso.org 1213 URI: http://www.iso.org 1215 Full Copyright Statement 1217 Copyright (C) The IETF Trust (2007). 1219 This document is subject to the rights, licenses and restrictions 1220 contained in BCP 78, and except as set forth therein, the authors 1221 retain all their rights. 1223 This document and the information contained herein are provided on an 1224 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1225 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1226 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1227 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1228 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1229 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1231 Intellectual Property 1233 The IETF takes no position regarding the validity or scope of any 1234 Intellectual Property Rights or other rights that might be claimed to 1235 pertain to the implementation or use of the technology described in 1236 this document or the extent to which any license under such rights 1237 might or might not be available; nor does it represent that it has 1238 made any independent effort to identify any such rights. Information 1239 on the procedures with respect to rights in RFC documents can be 1240 found in BCP 78 and BCP 79. 1242 Copies of IPR disclosures made to the IETF Secretariat and any 1243 assurances of licenses to be made available, or the result of an 1244 attempt made to obtain a general license or permission for the use of 1245 such proprietary rights by implementers or users of this 1246 specification can be obtained from the IETF on-line IPR repository at 1247 http://www.ietf.org/ipr. 1249 The IETF invites any interested party to bring to its attention any 1250 copyrights, patents or patent applications, or other proprietary 1251 rights that may cover technology that may be required to implement 1252 this standard. Please address the information to the IETF at 1253 ietf-ipr@ietf.org. 1255 Acknowledgment 1257 Funding for the RFC Editor function is provided by the IETF 1258 Administrative Support Activity (IASA).