CIP-0068 | Bump version for RFT

[KtorZ]

• Move CIP to Active
• Require version >= 2 for RFT metadata
• Clarify the use of the version number
• Introduce succinct changelog for major version changes
• Align CIP with new CIP-0001 format

Fixes #520.

cc @rphair @Ryun1 @alessandrokonrad @AndrewWestberg @mmahut @SmaugPool

[rphair]

thanks, looks complete & effective to me ⭐ #520 (comment)

[alessandrokonrad]

I don't quite understand why the version of an independent sub standard needs to be bumped just because a new asset name label is used? They all have nothing to do with each other. version here is meant to bumped independently for a specific label in case new properties will be added in the future or a new format is agreed on.
E.g. let's take the label 222. It represents NFTs with a focus on media files. Let's say there is a better metadata format for it, then this new format can be adopted by incrementing the version field. You don't introduce a new label in this case, because you want to be in exactly the same category/class.
So labels are for introducing completely new asset classes/categories and versions are for adding/changing the metadata format of that class over time. Maybe the version never changes, but it gives you extra flexibility.
Why should 444 start with version 2?. Each sub standard can almost be seen as its own little CIP. They are all independent.

[KtorZ]

@alessandrokonrad you have to put an implementor hat on, like 5Binaries or Smaug or any wallet provider actually that seek to support the CIP. If the CIP keeps changing and new formats / asset classes are added, we end up in a similar situation to CIP-0030 where everyone is implementing it but no one is actually implementing the same thing. Then, from a user perspective, it's hard to know what version of the CIP is actually supported.

Thus, we need to have an overarching version number that is incremented when significant changes are made. Introduce a new asset class falls in this category. And indeed, modifying the format of a single one should also lead to a version increase.

These can't be decoupled in practice because they're part of the same CIP. So they will always be considered as a bundle.

[alessandrokonrad]

Thus, we need to have an overarching version number that is incremented when significant changes are made. Introduce a new asset class falls in this category. And indeed, modifying the format of a single one should also lead to a version increase.

Yes I get this and it makes sense, however this is not the intention of the version field in the datum. CIP-0068 is the base structure and all those sub standards utilize it. They really can be seen as their own independent standards. We could seperate them and have them as their own CIPs, but I feel like this is overkill for some token standards based on CIP-0068.
I don't see CIP-0068 as a place where all new token standards will be added. It was fine for the first 2-3, but if more sub standards are added we should separate them. That's why I think bumping the version field for certain sub standards doesn't make a lot of sense and imo is confusing.

[Crypto2099]

Since this has been on the books a while and the contents of CIP-68 have changed substantially I think we should submit this one for triage, rebasing, and reconsideration during the next CIP Editors Meeting. Thoughts @rphair @KtorZ?

[rphair]

yes that's great @Crypto2099 - I knew this material had several upcoming concurrent changes and really wanted to incorporate the above into the baseline back in June, especially since the versioning question already appeared settled by @Ryun1's additions to CIP-0001. Some of the items in the OP I think are done already & we can confirm whatever remains... I've added it to next week's agenda.

I also think there could be a case for a CIP specification for Beacon Tokens so I would also like to get the CIP-0068 platform fully straightened out before I make that pitch to the developer 🧐

p.s. I've put it in the agenda sequence after CIP-0072 which I think is a "quickie" (maybe even a last-check) but before "Domain Name Resolution" which is a long-term, open-ended, non-urgent problem.