31 Mar
2026
31 Mar
'26
11:28 a.m.
On 31 Mar 2026, at 12:20, Matthew Wild <mwild1(a)gmail.com> wrote:
On Tue, 31 Mar 2026 at 12:09, Marvin W. via Standards
<standards(a)xmpp.org> wrote:
I think this is also all fair.
A think we used to do, rarely, once upon a time, was having new specs as new documents,
and as they got (lowercase) stable rolled them into existing documents. I suppose that
would be an option here that would both address Marvin’s “we might need to change this
after publishing” and Matthew’s “Let’s not duplicate the MUC fragmentation”.
/K
On Tue, 2026-03-31 at 11:59 +0100, Kevin Smith
wrote:
I'm fine with this, if it's the consensus of the community/Council.
I agree we are far from "everything in one specification", but I think
there is a balance to strike between having every little feature in
individual XEPs, and having everything related to, say, archive
management, in one place. MUC is suffering from the effects of the
"small bolted on XEPs" approach right now, and it makes it a pain for
implementers to figure out what's what. I think Matthew’s change is doing this the right
way for Stable -
Stable allows changes to the XEP as long as they’re
backwards/forwards compatible, which AFAICS Matthew’s proposal is.
I don't disagree that it is formally correct and allowed to have this
change in a Stable XEP, but I believe the feature in of itself is more
of Experimental quality, meaning we might want to do changes to it that
are not backwards-compatible. If we introduce it into a Stable XEP, we
can't do that. I also fail to see the benefit of adding it to the
existing XEP over creating a new one.
After all, we intentionally have multiple XEPs and not one single
specification with a lot of optional parts. Denoting the status of
features within our specification set is one of the benefits we earn
from doing so. Let's make good use of it.