Open TelegramSam opened 1 year ago
@dhh1128 @swcurran @rodolfomiranda ^
For that particular case, I'd say that having everything in the protocol definition would be convenient, at least up to the point that it become unmanageable. What other non-protocol info do you foresee? I'm asking because how to classify the information is relevant. The rfc-way it's simple but too generic and finding stuff is difficult.
The protocol definition feels to me like the right home. We already list a bunch of different types of info that you can query for, and we say that more can be added. Just specifying DID methods as another type seems easy and natural.
It would be useful to be able to query and disclose support for DID Methods using the Discover Features protocol. Where should this documentation go?
In the Aries world, I'd create an RFC describing the necessary things that would apply to the Discover Features protocol. Here on didcomm.org, we don't have a place for non-protocol documents.
So, where should this go? Should we update the Protocol definition to include this new type of feature and the details of expression? Should we add a way to include non-protocol documents? What's the right answer here?