The spec currently has the currency member being defined as a 3 letter alphabetic currency code. I recommend changing this to either an unlimited length and otherwise unconstrained currency code, or to a full currency name.
The note on the spec does mention following a future standard, as currently written it cannot do this (without backward incompatibility) if the new standard uses currency codes longer than 3 letters, or allows for a broader set of characters than just upper case Latin letters. The note also mentions that implementations will allow well formed non-standard currencies, but there are many digital currencies already in existence that don't fit within the 3 capital letter constraint.
My preference is to just use a full unrestricted string, and state that ISO4217 should be used if possible for the name of the currency, but future naming standards can be adopted and non-standard currency names can be used by implementations as needed. This would remove all constraints on the namespace, while improving implementation readability, as well as removing all current ambiguities and minimizing the chance of future ambiguities.
The spec currently has the
currencymember being defined as a 3 letter alphabetic currency code. I recommend changing this to either an unlimited length and otherwise unconstrained currency code, or to a full currency name.The note on the spec does mention following a future standard, as currently written it cannot do this (without backward incompatibility) if the new standard uses currency codes longer than 3 letters, or allows for a broader set of characters than just upper case Latin letters. The note also mentions that implementations will allow well formed non-standard currencies, but there are many digital currencies already in existence that don't fit within the 3 capital letter constraint.
My preference is to just use a full unrestricted string, and state that ISO4217 should be used if possible for the name of the currency, but future naming standards can be adopted and non-standard currency names can be used by implementations as needed. This would remove all constraints on the namespace, while improving implementation readability, as well as removing all current ambiguities and minimizing the chance of future ambiguities.