During our working group today we identified that the supported standards pattern in ICRC-1 implies that you have to implement the entire standard to support this endpoint. It was suggested that we generalize this as we are about to make the same “mistake” in ICRC7. I wrote up the following proposal and hopefully, we can fast-track it to generalize this input for broader interoperability.
https://github.com/skilesare/ICRC/tree/icrc61/ICRCs/ICRC-61
I’d also suggest that perhaps we drop icrc7_supported_standards and point to this ICRC for where to expose your supported standards.
It would be nice to fast-track this one, so please review and comment.
7 Likes
Thanks, @skilesare, for writing this proposal up, makes lots of sense to me!
My proposal is to discuss and hopefully decide the use of this in ICRC-7 in the upcoming Working Group meeting. The standard proposal is already updated to reflect this, anticipating that people will like it. A rollback is always possible otherwise.
3 Likes
The proposal has been updated with the discussed changes during the working group. Namely:
- ICRC-7 has been removed as it will implement ICRC-61.
- The method should have a self-reference to ICRC-61 in its return.
icrc1_supported_standards MUST still be maintained by icrc1(and derivative) implementations.
1 Like
I merged Austin’s PR into the main repo and made some small changes.
Current draft
There are a few comments I’d like your inputs on, then we can go for an NNS vote.
@skilesare: Can you also give me your OK for my changes?
@skilesare, @sea-snake, @benji, all
@Severin can you change the topic to ICRC-10?
3 Likes