idnits 2.17.1 draft-stanish-x-iso4217-a3-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2012) is 4179 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Walter Stanish 2 Intended status: Informational The IFEX Project 3 Expires: May 13, 2013 ifex-project.org 4 November 2012 6 Registry of Unofficial Extensions to the ISO 4217 Alpha Three Currency 7 Identification Namespace (X-ISO4217-A3) 8 draft-stanish-x-iso4217-a3-00 10 Abstract 12 This document defines a new IANA registry to keep track of 13 identifiers for currencies or currency-like commodities lying outside 14 the traditional scope of the International Organization for 15 Standardization (ISO) 4217 alpha-3 standard, such as digital 16 currencies and commodities, currencies issued by countries (nation- 17 states) with limited international recognition, emerging commodities 18 such as emissions reduction credits, private or commercial 19 currencies, and accounting units for local exchange and trading 20 systems (LETS). Such codes are already in use; the registry simply 21 codifies their existence. 23 Status of this Memo 25 This memo defines an Experimental Protocol for the Internet 26 community. This memo does not specify an Internet standard of any 27 kind. Discussion and suggestions for improvement are requested. 28 Distribution of this memo is unlimited. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This document is an individual submission. Comments are solicited 41 and should be addressed to the author(s). 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 This Internet-Draft will expire on May 13, 2013. 48 Copyright Notice 50 Copyright (c) 2012 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 1. Introduction 65 The vast majority of multicurrency financial systems today use the 66 International Organization for Standardization (ISO) 4217 standard 67 for currency identification, which provides three digit numeric and 68 three letter ("alpha-3") codepoints for the identification of each 69 currency. The latter, letter-based codes are in far greater use. 71 ISO4217 codepoints are registered by the International Organization 72 for Standardization through the maintenance agency for the registry, 73 SIX Interbank Clearing [SIX], a Swiss financial body. 75 The specific terms of SIX or the ISO's mandate within the currency 76 sphere do not appear to be publicly available. However, given that 77 geographically defined nation-states with some international 78 recognition and physically circulating currency (such as Transnistria 79 [PRB]) have not been issued currency codes, and leaving aside the 80 relatively large scope for raising conflict of interest questions 81 with regards to SIX's SWIFT links, it is reasonable to assume that 82 SIX and the ISO's mandate and/or sphere of interest in the currency 83 domain is highly unlikely to suddenly extend to emerging currency- 84 like commodities lacking some or all of the political qualities 85 exhibited by conventional currencies. 87 At present, issued codepoints are almost exclusively linked to 88 national or supra-national entities (eg. 'EUR' for the Euro, the 89 currency of the European Union) that have achieved political 90 recognition from the United Nations, with some exceptions for the 91 more popular traditional commodities, such as gold, and various 92 regional instruments backed by similar political entities. 94 This is understandable, given that conventional definitions of the 95 term 'currency' are often inextricably linked to the notion of 96 national issue by 'countries' or nation-states: 98 "a system of money in general use in a particular country" 99 -- The Oxford Dictionary [OXFORD] 101 Therefore currencies and currency-like commodities with far smaller 102 circulation not adopting a traditional national paradigm of issue are 103 unlikely to be granted a codepoint. Indeed, there is some evidence 104 that SIX Interbank Clearing has rejected proposals for such 105 registrations in the recent past, citing lack of a national entity 106 backing a particular currency. [ISO-REJECTION] 108 This situation has left both end users and system developers and 109 integrators in a quandry; in response they have apparently near 110 uniformly opted to respond by issuing unofficial ISO4217 alpha-3 111 codes for private use. 113 The present problem is that, given the recent growth of such 114 unofficial codes, and the increasing exchange of such assets across 115 disparate systems, no registry of unofficial codepoints exists. 116 Therefore no unambiguous, internet-wide, shared vocabulary can be 117 adopted by internet systems to identify this emerging class of 118 assets. 120 This document proposes the establishment of a registry to be 121 maintained by the Internet Assigned Numbers Authority (IANA) in order 122 to resolve this issue by creating an unofficial, parallel namespace 123 codifying such unofficial extensions to the ISO4217 alpha-3 official 124 standard, tracking present and future unofficial assignments. 126 Examples of currencies or currency-like commodities for which systems 127 may benefit from such registration include decentralized digital 128 currencies such as Bitcoin [BITCOIN], the upcoming Ripple Credit 129 [XRP], private currency systems [SLL], and regional currencies of 130 limited political recognition [PRB] [TEM]. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in BCP 14, RFC 2119 135 [RFC2119]. 137 Table of Contents 139 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 140 2. X-ISO4217-A3 . . . . . . . . . . . . . . . . . . . . . . . . . 6 141 2.1. Examples. . . . . . . . . . . . . . . . . . . . . . . . . . 6 142 2.2. Source Registry Identification. . . . . . . . . . . . . . . 6 143 2.3. Codepoint Identification. . . . . . . . . . . . . . . . . . 6 144 3. Implementation Considerations. . . . . . . . . . . . . . . . . 7 145 3.1. Machine Presentation. . . . . . . . . . . . . . . . . . . . 7 146 3.2. End User Presentation . . . . . . . . . . . . . . . . . . . 8 147 3.3. Input . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 148 3.4. Case Sensitivity. . . . . . . . . . . . . . . . . . . . . . 8 149 3.5. Internationalization. . . . . . . . . . . . . . . . . . . . 8 150 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 9 151 4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 152 4.1.1. Input Confirmation . . . . . . . . . . . . . . . . . . . 9 153 4.1.2. Case Normalization . . . . . . . . . . . . . . . . . . . 9 154 4.2. IANA Processes. . . . . . . . . . . . . . . . . . . . . . . 9 155 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 10 156 5.1. Name Space Exhaustion . . . . . . . . . . . . . . . . . . . 10 157 5.2. Registration. . . . . . . . . . . . . . . . . . . . . . . . 10 158 5.3. Modification / Cancellation . . . . . . . . . . . . . . . . 10 159 5.4. Publication . . . . . . . . . . . . . . . . . . . . . . . . 10 160 5.5. ISO Liason. . . . . . . . . . . . . . . . . . . . . . . . . 11 161 5.6. Security. . . . . . . . . . . . . . . . . . . . . . . . . . 11 162 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 163 6.1. Normative References. . . . . . . . . . . . . . . . . . . . 12 164 6.2. Informative References. . . . . . . . . . . . . . . . . . . 13 165 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 14 166 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 167 9. Appendix A: Initial Registry Contents. . . . . . . . . . . . . 15 168 10. Appendix B: Document History. . . . . . . . . . . . . . . . . 17 170 2. X-ISO4217-A3 172 The official [ISO4217] codepoints are considered a subset of a larger 173 namespace providing unambiguous identification of currencies and 174 currency-like commodities both within conventional ISO4217 175 assignment, and codepoints external to that registry in popular use, 176 the registry of which is to be managed by IANA. This goal is 177 achieved by providing a longer machine format for codepoints, whilst 178 respecting existing end user expectations regarding format and 179 presentation. 181 As a result, systems implementers can provide X-ISO4217-A3 support 182 and be safe in the knowledge that they will have the capacity to 183 support all ISO4217 alpha-3 codepoints. 185 2.1. Examples 187 The Euro is encoded as '0EUR'. 189 The digital currency or currency-like commodity known as Bitcoin is 190 encoded as 'XBTC'. 192 2.2. Source Registry Identification 194 In order to issue superset-compatible currency and currency-like 195 commodity identifiers within the [ISO4217] scheme, a prefix character 196 is introduced denominating the source registry, being either this 197 IANA-managed and unofficial registry (denoted with 'X') or the 198 official ISO-managed registry (denoted with '0'). 200 The 'X' notation is chosen as is the standard semantic for unofficial 201 extensions within internet drafts. The '0' notation is chosen as 202 implying an 'initial' or 'original' semantic (with the useful side- 203 effect of top-sort behaviour thus resulting). 205 2.3. Codepoint Identification 207 The X-ISO4217-A3 format may be expressed in ABNF [RFC5234] as 208 follows: 210 codepoint = registry a3code ; eg: '0EUR', 'XBTC' 212 registry = reg-iso / reg-iana ; ie: '0' / capital 'X' 213 reg-iso = "0" ; ISO4217-A3 (ISO managed) 214 reg-iana = %d88 ; X-ISO4217-A3 (IANA managed) 216 a3code = 3caps-letter ; eg: 'EUR', 'BTC' 218 caps-letter = %d65 / %d66 / %d67 / %d68 / %d69 / %d70 / %d71 / 219 %d72 / %d73 / %d74 / %d75 / %d76 / %d77 / %d78 / 220 %d79 / %d80 / %d81 / %d82 / %d83 / %d84 / %d85 / 221 %d86 / %d87 / %d88 / %d89 / %d90 ; ie. capital A-Z 223 An explanation of the major elements follows. 225 codepoint: 226 A structurally valid X-ISO4217-A3 codepoint in machine format, ie. 227 including the registry identifier. 229 registry: 230 A character identifying the source registry of the subsequent 231 'a3code' 232 being either 'X' (denoting this registry, managed by IANA) or '0' 233 (denoting the official ISO4217 registry, managed by SIX on behalf 234 of 235 the ISO). 237 a3code: 238 Alpha-three code. A three letter alphanumeric string identifying a 239 specific currency or currency-like commodity within the prior 240 'registry', as presently used within ISO4217 and unofficial 241 extensions 242 to the ISO4217 system, for example: 'EUR' (official ISO code 243 denoting 244 the Euro) or 'BTC' (widely used code denoting Bitcoin [BITCOIN]). 246 3. Implementation Considerations 248 3.1. Machine Presentation 250 In contrast to the existing practice of utilising ad-hoc vocabularies 251 for systems integration, X-ISO4217-A3 systems MUST provide the full 252 X-ISO4217-A3 code including registry identifier to all connecting 253 systems. 255 3.2. End User Presentation 257 For user presentation purposes, systems MAY wish to present the 258 'a3code' element to end users rather than the full X-ISO4217-A3 259 codepoint (eg: 'BTC' instead of 'XBTC'). In such cases, adequate 260 context SHOULD be given in order to prevent ambiguity. Adeqaute 261 context MAY include the option to view the full X-ISO4217-A3 262 codepoint, the human language currency name, and the source registry, 263 AND/OR the reconfirmation of any initiated operation with such 264 clarifying contextual information added prior to its actual 265 execution. 267 3.3. Input 269 Implementations SHOULD accept both X-ISO4217-A3 and ISO4217-A3 270 equally in all cases, such that end users are NOT aware of any 271 difference between the two standards. 273 In the event that users provide an 'a3code' as input, multiple 274 codepointrs The determination of 276 3.4. Case Sensitivity 278 Implementations MAY accept (structurally invalid) mixed or lower case 279 input, but SHOULD normalize this input to (structurally valid) upper 280 case prior to processing or storage. For relevant security 281 considerations, see Case Normalization. 283 Implementations MUST present only upper case normalized (structurally 284 valid) identifiers to both peer systems and end users. 286 3.5. Internationalization 288 The registry MAY include currency and entity names as arbitrary UTF8 289 strings. 291 To aid international recognition of individual codepoints, 292 implementations MUST present only upper case normalized (structurally 293 valid) identifiers to both peer systems and end users. (See Case 294 Sensitivity). 296 4. Security Considerations 298 X-ISO4217-A3 only provides a currency or currency-like commodity 299 identification scheme and DOES NOT approach problems of 300 communications security, which are purposefully left to other 301 protocols. Even so, some security considerations are are pertinent. 303 4.1. Input 305 4.1.1. Input Confirmation 307 Because there is always some scope for error in systems requiring end 308 user input (see Case Normalization), unambiguous confirmation of 309 input SHOULD be provided. Such confirmation MAY include the full X- 310 ISO4217-A3 codepoint, the human language currency name, and the 311 source registry. 313 4.1.2. Case Normalization 315 It should be noted with regards to case normalization that some 316 frequency of manual recognition or transposition errors is likely to 317 occur whenever input is sought. This frequency increases in 318 situations where an end user does not have linguistic or other types 319 of clues regarding a source document's probable vocabulary or 320 semantics, or is simply unfamiliar with the material. Machine-style 321 codes, such as X-ISO4217-A3, therefore fall in to a relatively high 322 risk area, albiet one that conventional ISO4217 systems are also 323 vulnerable to. 325 When considering the implementation of X-ISO4217-A3 systems that 326 accept lower or mixed-case input, implementers SHOULD consider 327 carefully whether case normalization is an appropriate choice for 328 their systems, given that the scope for such errors is nominally 329 (though not hugely) increased. (For example, an input of 'Z' could 330 come from a user misunderstanding a lowercase 'r', or an input of 'U' 331 could come from a user misunderstanding a lowercase 'a'.) To some 332 extent this issue SHOULD be mitigated by the requirement that 333 implementations MUST present only upper case (structurally valid) 334 codepoints both to peer systems and end users. 336 4.2. IANA Processes 338 IANA MUST provide adequate authentication of registrant institution 339 communications in order to prevent the subversion of established 340 institutions' registration information via IANA's registrar 341 functions. 343 5. IANA Considerations 345 5.1. Name Space Exhaustion 347 Should the entire IANA-managed portion of the X-ISO4217-A3 namespace 348 approach registration, IANA MUST immediately select an additional 349 registry prefix. 351 5.2. Registration 353 Codepoints MUST be assigned by IANA on a first come first served 354 basis [RFC5226]. To support innovation, in contrast to conventional 355 financial registries, codepoints MUST be issued to ANY registrant 356 supplying a valid domain name and reasonable information. 358 Registrants MUST provide the domain name with which their service is 359 primarily associated AND the name of the registrant (either a person 360 or an organizational entity), as well as the appropriate contents for 361 the registry fields. 363 Registrants MAY request a specific codepoint, or IANA MAY assign them 364 one. 366 5.3. Modification / Cancellation 368 Due to the nature of currency and currency-like commodity 369 identification between disparate financial systems, codepoint 370 allocations are permanent and binding. However, modifications to 371 metadata are possible and SHOULD be effected by IANA within a few 372 working days. IANA should update the 'modified' field of the 373 registry entry in question to reflect the fact that modification has 374 taken place. 376 5.4. Publication 378 IANA SHALL publish revisions to the global registry of X-ISO4217-A3 379 codes as changes are made. 381 IANA SHALL NOT include ISO4217 official codepoints for legal reasons. 383 IANA SHALL provide GPG-compatible cryptographic signatures along with 384 each version of the registry. IANA MAY provide additional cryptographic 385 signatures and/or checksums at their sole discretion. 387 The registry SHALL utilize UTF8 encoding in order to meet 388 internationalization requirements for institution names. 390 The format and initial contents of this registry document are specified 391 in Appendix A. 393 5.5. ISO Liason 395 IANA SHOULD formally notify [SIX] (as the maintenance agency of the 396 ISO4217 registry) of the existence of this registry. IANA SHOULD 397 make [SIX] feel welcome to forward parties unsuccessful in their 398 applications for ISO4217 codepoints to IANA, in order to acquire 399 alternate codepoint registrations within the IANA-managed X- 400 ISO4217-A3 registry. 402 5.6. Security 404 IANA MUST provide adequate authentication of registrant institution 405 communications in order to prevent the subversion of established 406 codepoints' metadata via IANA's registrar functions. 408 As IANA is likely to have superior experience in this domain, 409 specific procedures are left to IANA's judgement. 411 6. References 413 6.1. Normative References 415 [ISO4217] ISO. "ISO 4217 - Currency Codes", 416 http://www.iso.org/iso/home/standards/ 417 currency_codes.htm 419 [RFC2119] Bradner, S., "Key words for use in RFCs to 420 Indicate Requirement Levels", BCP 14, RFC 2119, 421 March 1997. 423 [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for 424 Writing an IANA Considerations Section in RFCs", 425 BCP 26, RFC 5226, May 2008. 427 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for 428 Syntax Specifications: ABNF", STD 68, RFC 5234, 429 January 2008. 431 6.2. Informative References 433 [BITCOIN] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic 434 Cash System", 2009-05-24. 435 http://www.bitcoin.org/bitcoin.pdf 437 [ISO-REJECTION] grossdigitalproduct, "getting BTC into ISO 4217 438 currency list", 10 November 2012. 439 https://bitcointalk.org/index.php?topic=123600 440 Relevant excerpt: 441 "I also understand you have previously denied 442 such requests with the following statements: 443 1. The currency code is not linked to any 444 country code. 445 2. The currency code is considered a 446 'private currency' and not used for 447 tender in any country. 448 3. There will be no international payments 449 denominated in Bitcoin therefore an ISO 450 currency code for the Bitcoin is not 451 applicable. 452 4. The Institution responsible for the 453 Bitcoin does not appear to be recognized 454 internationally or have any official 455 status. Neither Reuters or Bloomberg 456 provides market data related to its use." 458 [OXFORD] Oxford University Press, "Definition of currency" 459 http://oxforddictionaries.com/definition/english/ 460 currency 462 [PRB] Trans-Dniester Republican Bank, "History of coins 463 and banknotes". Retrieved November, 2012. 464 http://www.cbpmr.net/?id=33&lang=en 466 [SIX] SIX Interbank Clearing 467 http://www.six-interbank-clearing.com/ 469 [SLL] "Economy of Second Life" 470 http://en.wikipedia.org/wiki/Economy_of_Second_Life 472 [TEM] Exchange and Solidarity Network of Magnesia, 473 "Alternate Monetary Unit" 474 http://www.tem-magnisia.gr/ 476 [XRP] OpenCoin, Inc. "Ripple open source payment system" 477 http://ripple.com/ 479 7. Acknowledgments 481 * Payward, Inc. funded the research and development of this 482 document. 483 * OpenCoin, Inc. provided valuable feedback. 484 * The (completely OMC unaffiliated) OpenSimulator project staff were 485 helpful in clarifiying the origin and status of OMC. 487 8. Authors' Addresses 489 Prepared by Walter Stanish of Payward, Inc. on 490 behalf of The Internet Financial EXchange (IFEX) Project: 491 http://www.ifex-project.org/ 493 9. Appendix A: Initial Registry Contents 495 Prior to IANA handover, parties wishing to acquire an identifier may do 496 so by contacting the IFEX Project via ifex-project.org 498 # X-ISO4217-A3: Unofficial ISO4217 Alpha-3 Extensions Registry. 499 # 500 # Version: 20121113-0 501 # (Format is
-, where x is a digit from 0-9) 502 # 503 # To be cryptographically signed by IANA and replicated freely. 504 # 505 # Format: 506 # - Lines beginning with '#' are comments. 507 # - Whitespace should be ignored. 508 # - Fields at the end of a record may be absent. 509 # - Records are comprised of the following fields (ABNF): 510 # country-code institution-code "|" created "|" modififed \ 511 # "|" domain "|" registrant "|" fingerprint 512 # 513 # Fields: 514 # registry Registry of origin. 'X' denotes IANA X-ISO4217-A3. 515 # a3code Three character code identifying the currency or 516 # currency-like commodity within a registry. 517 # name-singular Singular form name of the currency (or primary unit) 518 # e Number of post-decimal digits in normal use. 519 # created Date of registration (YYYY-MM-DD). 520 # modified Date last modified (YYYY-MM-DD), or blank. 521 # domain Primary domain name associated with the record. 522 # registrant Native language name of the registrant (UTF8). 523 X|ACD|Avination Care Dollar|2|2012-11-13||avination.com|Avination 524 Virtual Limited 525 X|BTC|Bitcoin|8|2012-11-13||bitcoin.org|Bitcoin Community 526 X|CER|Kyoto Protocol Certified Emissions Reduction CO2 527 Tonne|4|2012-11-13|||United Nations Framework Convention on Climate 528 Change 529 X|OMC|Open Metaverse Currency|2|2012-11-13||Open Metaverse Currency 530 Community 531 X|PRB|Transistrian Ruble|0|2012-11-13||cbpmr.net|Trans-Dniester 532 Republican Bank 533 X|SLL|Second Life Linden Dollar|0|2012-11-13||secondlife.com|Linden 534 Research, Inc. 535 X|TEM|Volos Alternative Monetary Unit|0|2012-11-13||tem- 536 magnesia.gr|Volos Alternative Monetary Unit Community 537 X|VER|Non Kyoto Protocol Verified Emissions Reduction CO2 538 Tonne|4|2012-11-13|||Non Kyoto Protocol Verified Emissions Reduction 539 Community 540 X|XRP|Ripple Credit|6|2012-11-13||ripple.com|OpenCoin Inc. 542 10. Appendix B: Document History 544 draft-stanish-x-iso4217-a3-00 (2012-11-13) 545 Initial release.