View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008020 | Taler | other | public | 2023-12-20 09:37 | 2024-03-07 19:47 |
| Reporter | Florian Dold | Assigned To | Christian Grothoff | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.9.4 | Fixed in Version | 0.9.4 | ||
| Summary | 0008020: address and clarify confusion in CurrencySpecification | ||||
| Description | Currently, multiple components / parts of the documentation have different interpretations of the CurrencySpecification. Either: (a) the currency code is part of the CurrencySpecification (b) the currency code is served *alongside* the CurrencySpecification, either as a sibling member in a JSON object or as the key in a mapping from currency to CurrencySpecification I thought we had previously agreed that the CurrencySpecification should *not* contain the currency code. In discussions with Marc, it became clear that our team/specs/implementations are not aligned here yet. However, the exchange docs and implementation still have the currency field inside `CurrencySpecification`. DD51 doesn't have the field, libeufin-bank doesn't have the field either. | ||||
| Tags | No tags attached. | ||||
| Since the "currency" we use everywhere should BE the ISO 4217 code for real-world currencies, and must have >= 4 letters for regional currencies, we don't need this specified elsewhere. The DD51 currency specs already contains a “name” field: export interface CurrencySpecification { name: string; num_fractional_input_digits: Integer; num_fractional_normal_digits: Integer; num_fractional_trailing_zero_digits: Integer; alt_unit_names: { [log10: string]: string; }; } This “name” should be made optional and NOT be returned for ISO 4217 currencies. This name is only needed for regional currencies. When an App or WebEx needs the name of the currency, it should just ask the system it runs on for that (localized) name. For instance, iOS provides these Calls /// check whether a 3 letter code is a known ISO-4217 currency public var isISOCurrency: Bool /// Returns a list of `Locale` currency codes defined in ISO-4217 public static var isoCurrencies: [Locale.Currency] /// Returns a localized string for a specified ISO 4217 currency code. /// For example, in the "en" locale, the result for `"USD"` is `"US Dollar"`. public func localizedString(forCurrencyCode currencyCode: String) -> String? I am pretty sure Android has similar functions. | |
| Marc: Please don't presume all wallets are on iOS or Android. I don't see POSIX having "localizedString()". The 'name' field in the currency specification is the long name ("US Dollar"), not the currency code. This should stay, even for non-regional currencies, as some client platforms may not have a built-in list. | |
| Removed currency code field as of exchange protocol v18. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-12-20 09:37 | Florian Dold | New Issue | |
| 2023-12-20 09:37 | Florian Dold | Status | new => assigned |
| 2023-12-20 09:37 | Florian Dold | Assigned To | => Christian Grothoff |
| 2023-12-20 10:36 | MarcS | Description Updated | |
| 2023-12-21 19:18 | MarcS | Note Added: 0020782 | |
| 2023-12-21 19:20 | MarcS | Note Edited: 0020782 | |
| 2023-12-22 06:39 | Christian Grothoff | Note Added: 0020788 | |
| 2023-12-22 06:57 | Christian Grothoff | Note Added: 0020789 | |
| 2023-12-22 06:58 | Christian Grothoff | Status | assigned => informing |
| 2023-12-22 06:58 | Christian Grothoff | Resolution | open => fixed |
| 2023-12-22 06:58 | Christian Grothoff | Fixed in Version | => 0.9.4 |
| 2024-03-07 19:47 | Christian Grothoff | Status | informing => closed |