jdev - 2023-01-14

Did it like that in the Prosody error wrapper library, which tries to be somewhat ignorant of XML. The application-specific condition can be a tuple (condition, namespace) or a single XML element.

@Sam AFAIK, we've never defined an application-specific error condition that employs more than one child element of <error/>. IMHO conceptually that wouldn't be sensible, since it is a particular component (e.g., MUC) or code module (e.g., disco) that generates the application-specific condition - basically that piece of code further clarifies specifically why it's a bad-request error or whatever.

(It wouldn't make sense for the MUC module to say "here's why I think it's a bad request" and for the disco module to offer its own independent reason why it's a bad request, as it were...) ✏

PubSub uses some application-specific conditions. One could imagine an application using PubSub for something wanting to be even more specific in its errors.

nod

Thanks all; makes sense.

Reminds me of my unfinished XEP about s2s error conditions.

Given how uncommon application-specific conditions are, seems a bit hard to justify adding support for unlimited numbers of them...

Hello everyone, very last call for XMPP projects to submit their ideas and participation interest: https://wiki.xmpp.org/web/Google_Summer_of_Code_2023#Project_Ideas_(TO_BE_UPDATED_FOR_2023)