Hi Goffi!
Thanks for that PEP suggestion. I wonder if the use-case is indeed simplified by using a PEP service for the domain itself: consumers of the data would still need to perform an additional verification, right?
Instead of checking if the service advertises the serverinfo feature, consumers need to verify that the service is a PEP-service for the domain itself - which I think is basically done by checking for a _different_ feature?
Offering more than one way that 'opt-in' can be verified by a consumer complicates implementations. That complexity could be 'solved' by mandating exactly one of the options, but in that case the PEP solution is likely to be least supported by current server implementations. I would favor the existing option because of that.
As for the suggestion to switch to using the Clark notation for the new disco/info field: In my reading XEP-0068 mandates it only for fields not registered by the XSF itself. That doesn't apply to the field added by this pubsub-serverinfo XEP. That doesn't mean that we _cannot_ use Clark notation, of course, but what would be the benefit of moving to a Clark notation? I don't think it does away with the awkwardness of having either multiple XEP-0128-defined dataform-extensions, or merging them into one. I'm not immediately seeing a benefit of using Clark notation here.
I love to hear your thoughts on this!
Kind regards,
Guus