31 Mar
2026
31 Mar
'26
11:33 a.m.
On Tue, 31 Mar 2026 at 12:28, Kevin Smith <kevin.smith(a)isode.com> wrote:
On 31 Mar 2026, at 12:20, Matthew Wild <mwild1(a)gmail.com> wrote:
That does seem like a sensible compromise. Publish as a new XEP, but
with the option of rolling it into XEP-0313 before Final if we decide
(based on adoption, implementation/deployment experience) that it
passes the bar for that.
Regards,
Matthew
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”. 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.
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.